Android の動的なシステム アップデート Q: Project Treble は将来の Android バージョンをどのように改善するか

いっぱいNov 09, 2023
click fraud protection

Google は、ブートローダーのロックを解除する必要がなく、Android Q に GSI をインストールする新しい方法である動的システム アップデートを明らかにしました。

Android 8.0 Oreoのリリースに合わせて、Googleは発表した プロジェクト・トレブル: Android OS フレームワークとベンダー HAL、Linux カーネルの通信方法の大幅な再設計。 Treble は、Android プラットフォームのバージョンを削減し、 セキュリティパッチの断片化、Android Pie で起動するすべての Android ブランドのデバイスは、Project Treble をサポートする必要があります。 OEM とベンダーは、汎用システム イメージ (GSI) (AOSP からの Android の純粋なストック ビルド) を起動し、 ベンダーテストスイート (VTS) および汎用システム イメージ上の互換性テスト スイート (CTS-on-GSI)。 GSI は、OEM で働くソフトウェア エンジニアが Treble の互換性をテストできるようにするだけでなく、 大規模なカスタム ROM コミュニティ XDAで。 Android Q リリースでは、Google は GSI を別のグループ、つまりアプリ開発者にとって役立つものにしたいと考えています。

通常、特定の Android プラットフォーム リリースの最初の安定版リリースとソース コード ドロップは、 8月に、実際のデバイスで次の Android リリースをテストしたい開発者は、アップデートが自分のハードウェアに届くのを待ちたくない場合、通常、Google スマートフォンにアクセスする必要があります。 ただし、Google は OEM と協力して、 Android P ベータ版 昨年はいくつかのデバイスに対応しましたが、今年はそれに続き、 Android Q ベータ版. 公式の Android Q ベータ版と並行して、Google は今年、 公式QベータGSI そのため、Project Treble と互換性のあるデバイスを持っている開発者は、ビルドがデバイスに届くまで何ヶ月も待つことなく、最新の Q リリースをインストールできます。 次期 Android リリースをテストするこの新しい方法により、開発者はより多くの機会を得ることができ、より多くの時間をかけてアプリをテストできるようになります。 Androidの大きな変更点.

残念ながら、現在の方法では、 GSI のインストール 難しいかもしれません。 これには、ブートローダーのロックを解除し（すべてのユーザー データを消去するか、保証を無効にすることを意味します）、fastboot プロトコル経由でイメージをフラッシュする必要があります。 アプリ開発者にとって、これは迅速かつ簡単なプロセスではありません。 ブートローダーのロックを解除することもできます. だからこそ、 ここ数ヶ月, Google は GSI を起動する新しい方法に取り組んでいます。 Dynamic System Update (DSU) と呼ばれる新機能を入力します。

(この機能は、以前は「Live Image」、「Dynamic Android」、「Android on Tap」という名前で開発されていたため、数週間または数か月後に Google が別の名前に変更したとしても驚かないでください。)

Android Q の動的なシステム アップデート

DSU 機能の目的は、開発者が現在のインストールを妨げることなく GSI を起動できるようにすることです。 つまり、ブートローダーのロックを解除する必要がなく、ユーザー データを消去する必要もありません。 Google は ADB 経由のコマンドライン インターフェースと、インテント経由で制御できるアプリを提供しているため、インストール プロセスも大幅に簡素化されています。 DSU を使用して GSI をブートすると次のようになります。

このビデオ* では、Android Q ベータ 3 を実行している Google Pixel 3 XL が GSI で再起動されます。 この環境では、アプリ開発者はアプリをインストールして、Q API の互換性をテストできます。 テストが完了したら、再起動するだけでデバイス上の通常の Q ベータ 3 ソフトウェアに戻ることができます。 基本的に GSI をデュアル ブートしているので、アプリを安全にテストできます。

*このビデオは、DSU がまだ一般公開されていなかった Google I/O 2019 で録画したため、撮影された Pixel 3 XL 上の Q ベータ 3 ビルドは、DSU サポートを含めるために Google によってわずかに変更されました。 Q ベータ 4 以降を実行しているデバイスは、以下の要件を満たしていれば DSU をサポートできます。

動的システム更新の要件

本質的にデュアルブートであるものを起動して実行することは、Google にとって簡単な作業ではありませんでした。 Google の DSU のテストベッドである Pixel 3 では、パーティションの管理方法に大きな変更を加える必要がありました。 したがって、DSU サポートの最初の主要な要件は、デバイスが 動的パーティション. 動的パーティションには、システム、ベンダー、ODM、OEM、製品などのサイズ変更可能な論理パーティションに分割されたストレージの 1 つの実際のパーティションが含まれます。 GSI のインストール中に、既存のユーザーデータ パーティションから未使用のブロックを取得することにより、新しいシステム パーティションとユーザーデータ パーティション用のスペースが予約されます。 これらの新しいパーティションのサイズは数ギガバイトになる可能性があるため、DSU サポートは論理的な場合にのみ意味を持ちます。 そうしないと、デバイスは GSI 用に数ギガバイトのストレージ スペースを永続的に予約する必要があります。 インスタレーション。

その他の要件には、リカバリ、システム、または論理パーティションのいずれを起動するかを決定する RAM ディスクと、GSI のメタデータを保存するメタデータ パーティションが含まれます。 一般に、DSU サポートの構成要素は Android Q の起動要件です。、プロジェクト・トレブルのリーダー、イリヤン・マルチェフ氏によると。 どうかは分かりません すべて DSU をサポートするために必要なこれは Android Q の起動要件ですが、すべてではないにしてもほとんどのデバイスが Android Q で起動すると推測できます。 できる Google が現在要求していない場合でも、DSU をサポートします。 これまでのところ、Pixel 3、Pixel 3 XL、Pixel 3a、Pixel 3a XL のみが動的パーティションを備えており、これらのデバイスのうち、Android Q ベータ 4 で DSU をサポートしているのは Pixel 3 と Pixel 3 XL だけです。 DSU サポートは必須ではありませんが、Treble 互換性の安全なテストが簡単になるため、Google は OEM がこの機能を有効にすることを望んでいます。 たとえば、OEM ソフトウェア エンジニアは GSI を配置できます。 SDカード上にある そのため、複数のデバイスですばやく起動して Treble の互換性をテストできます。

動的システム更新のためのセキュリティ

DSU は基本的に 2 番目のオペレーティング システムを混合に導入するため、Google は、この新しいインストールが改ざんされてデバイスの完全性が損なわれないようにする必要があります。 したがって、 元のインストールと同じ基本的なセキュリティ保護が GSI インストールにも適用されます: Android 検証済みブートおよび SELinux ポリシー。 さらに、INSTALL_DYNAMIC_SYSTEM 署名|特権権限を持つアプリのみが GSI を開始できます。 インストール中、MANAGE_DYNAMIC_SYSTEM 署名権限を持つアプリは GSI を有効化/無効化、または消去できます。 インストール。 これは、信頼できるシステム レベルのアプリのみが DSU と連携できることを意味します。

元のユーザー データが確実に保護されるように、Google は 追加の保護メカニズム Android Qで。 と呼ばれるチェックポイント」の機能は、チェックポイントが設定されたパーティションを元の状態に復元することで、ユーザー データの破壊を防ぎます。 ただし、チェックポイントは DSU だけではありません。 失敗を防ぐためにも使用されます プロジェクトのメインライン APEXモジュールと A/B OTAアップデート。 (A/B パーティションを持つデバイス すでにロールバック保護が備わっていますが、それらのロールバックには工場出荷時のデータへのリセットが必要ですが、ユーザー データ チェックポイントには必要ありません。)

GSI のインストール

お使いのデバイスが Pixel 3 シリーズなどの DSU をサポートしている場合は、GSI を簡単にインストールできます。 まず、次の 2 つの方法のいずれかで、動的システム機能フラグが有効になっていることを確認する必要があります。

  1. userdebug ビルドを使用している場合は、[設定] > [システム] > [開発者向けオプション] > [機能フラグ] で settings_dynamic_android フラグを有効にします。
  2. ユーザー ビルドを使用している場合は、次の adb シェル コマンドを実行します。
    setproppersist.sys.fflag.override.settings_dynamic_system 1

次に、最新の Android Q ベータ GSI を次のサイトからダウンロードします。 グーグル またはデバイスの OEM。 (DSU では、Google または OEM によって署名された GSI のインストールのみが許可されます。) ダウンロードしたら、使用します。 simg2img スパース画像を生画像に変換します。 gzip を使用して生のイメージを圧縮し、結果として得られたアーカイブをデバイス上の場所にコピーします。 外部ストレージ (例: /data/media/0/Download) または実際の外部ストレージ メディア (物理 SD など) カード）。 最後に、インストールを開始するための適切な目的で DynamicSysteminstallationService アプリを起動します。

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

[再起動] をクリックすると、GSI が起動します。 GSI でのデバイスの使いやすさは、デバイスの OEM が Treble をどの程度適切に実装しているか (あるいは、Treble にどれだけ違反していないかによって決まります) 互換性があります。) 一部のデバイスは他のデバイスよりも GSI でより適切に動作しますが、一般に、このインストールを日常的に使用することを期待しないでください。 運転者。 アプリをテストしてから再起動して終了することになっています。 さらにテストするために GSI インストールに留まりたい場合は、 gsi_tool シェルコマンド。

DSU の完全な GSI インストール手順については、こちらをご覧ください。 ここ. バグは次の場所に報告できます。 Google の問題トラッカー、レディット、 または スタックオーバーフロー.

動的システム更新の背後にある理由

Google I/O で Iliyan Malchev 氏と話したとき、彼は Treble チームの Hung-ying Tyan 氏が初期の GSI アクセスについて述べたことを繰り返し述べました。 11 月の Android Dev Summit. Google が DSU を作成したのは、 できるだけ幅広い聴衆からフィードバックを求める. 目標は、GSI の品質を向上させることです。 将来の Android リリースの品質を向上させる GSI は Android の最も純粋な形式であるためです。 現在、次期バージョンの GSI 互換性 (たとえば、Android Q システム イメージが Android P 上でどの程度機能するかなど) をテストしている唯一の企業は Google です。 ベンダーの実装）、しかし、より多くの人々が GSI をフラッシュしてフィードバックを提供するにつれて、OEM は Treble 互換性違反を修正できるようになり、GSI がより適切に機能するようになります。 未来。 Iliyan 氏によると、OEM や Qualcomm などのベンダーは、以前の Android リリースのベンダー イメージを次のバージョンのシステム イメージで再利用することに強い関心を持っています。 DSU のような取り組みは、Google や OEM が VTS や CTS-on-GSI などの自動テストによるカバレッジのギャップを埋めるのに役立ちます。 そのため、Google はより多くのベータ テスターを集めて次の Android リリースに関するフィードバックを提供してもらうと同時に、OEM が作業を改善できるように Treble 互換性違反についても聞きます。

Android Q に動的システム アップデートが追加されたのは歓迎ですが、一部の人が期待しているデュアル ブート ソリューションにはなりません。 前述したように、インストールできるのは、Google または OEM によって署名されたシステム イメージのみです。 代替 Android のエコシステムをサポートするために DSU を拡張する可能性について Iliyan に尋ねたところ、 DSU は単にシステムを提供するチャネルであるため、技術的にはそれが可能であると彼は述べました。 画像。 どの OEM も好きなように使用できます 最終結果が Android に準拠している限り. Google はここでは OTA システムの代替手段を作成していません。また、DSU は真のデュアル ブートに使用することを意図していません。 いずれにせよ、Google が Treble で行った取り組みにより、Android はよりモジュール化されているため、ネイティブ デュアル ブートが将来現実になったとしても驚かないでしょう。