Android 11 の DSU Loader は、開発者がストック Android でアプリをテストするのに役立ちます

優れたアプリのエコシステムは、オペレーティング システムの成功の最も重要な柱の 1 つです。 Google と Apple はどちらも、自社のプラットフォーム上に優れたアプリケーションを搭載することの価値を認識しているため、ユーザーとアプリ開発者のニーズのバランスを取るよう努めています。 ユーザーは OS の変更を求め続けており、ほとんどの人は一般に新機能を高く評価していますが、これらの機能は 変更は多くのコア機能を変更する可能性があるため、アプリ開発者にとって必ずしも楽しいものではありません。 行動。 アプリの関連性を維持するために常に取り組んでいる開発者にとって、これらの変更への対応は、増大する作業リストに追加されます。 これらの変更がアプリケーションに直接影響しない場合でも、開発者はアプリケーションが新しい OS アップデートでも動作することを確認する必要があります。 Google は、Android アプリ開発者にとってこのプロセスを容易にするために、長年にわたって多くの変更を行ってきました。 Android 11 の DSU Loader と呼ばれる機能により、アプリ開発者は新しい Android でアプリをテストすることがさらに簡単になります。 バージョン。

それはプロジェクト・トレブルから始まります

Android 8.0 で導入された Project Treble は、 Android OSの再構築. Project Treble の目標は、Android OS をフレームワークとベンダー実装という 2 つの大きな部分に分割することでした。 (ここでの「ベンダー」とは、デバイス内にある独自のハードウェア コンポーネントのメーカーを指し、通常は ケイ素）。 Android OS フレームワークは、すべてのシステム アプリ、UI とそのコンポーネント、Android デバイス間で共有される API を含むオペレーティング システム自体です。 ベンダー実装には、ベンダー HAL (ハードウェア アブストラクション レイヤー)、Linux カーネル、および Linux カーネル モジュールが含まれています。

OEM は、さまざまなベンダーのさまざまなハードウェア コンポーネントを搭載したスマートフォンを出荷するため、ハードウェアを単一の Android OS リリースで稼働させるだけでも多くの作業を行う必要があります。 そして、Android OS が新しくアップデートされるたびに、ハードウェアが新しいバージョンで動作することを確認するためにさらに多くの作業を行う必要があります。 しかし、Project Treble が Android OS フレームワークと特定の Android バージョンの HAL の間の ABI (Application Binary Interface) を標準化することで、 Android OEM は、シリコン メーカーや他のコンポーネント メーカーが自社側のアップデートを行うのを待つことなく、デバイスのアップデートのテストを開始できます。 コード。 この変化は著しく加速しました Android アップデートの処理方法.

これが Android アップデートに関して Project Treble が行ったことの要点ですが、アプリにとってより重要なことは 開発者は、Treble が互換性のために汎用システム イメージ (GSI) の使用を有効にしていると述べています。 テスト中。

GSIの登場

OEM が Project Treble を適切に実装しているかどうかをテストするために、Google は OEM がデバイス上で AOSP から Android のクリーン ビルドを起動できるようにすることを義務付けています。 この Android のクリーン ビルドは、汎用システム イメージ (GSI) と呼ばれます。 GSI が起動し、ほとんどの基本的なハードウェアが適切に機能する場合、OEM はデバイスが Project Treble の要件を満たしていることを認識します。 したがって、GSI の当初の目的は Treble の互換性をテストすることでしたが、ここ XDA-Developers の開発コミュニティで見てきたように、GSI は他の目的にも使用できます。 GSI がどのように機能するかを見ました これにより、基本的に、重い Android UX を搭載したデバイスが、新しいリリースから数日以内に、動作する機能を備えた最新バージョンの Android を楽しめるようになる可能性があります。 しかし、Google は GSI の背後に別の目的を想定しています。それは、アプリ開発者がすでに所有している物理デバイス上の新しい Android バージョンでアプリをテストできるようにすることです。

Android 10 では、Google が開発者向けに独自の GSI ビルドをリリースしました。 Google は、アプリ開発者は GSI を使用して独自のハードウェア上で Android のクリーン ビルドを起動し、標準の Android に対してアプリケーションの動作をテストしやすくする必要があるという考えを固めました。 したがって、この方法は、OEM の動作を変更せずに標準の Android でアプリの互換性をテストする既存のオプションに追加されました。その他のオプションは次のとおりです。 Pixel スマートフォンを使用するか、Android Studio 内の公式 Android エミュレータを使用するか、アプリのビルドをクラウド上のデバイス インスタンスにデプロイします。

GSI はあらゆる利便性をもたらしましたが、その設置は依然として面倒なプロセスでした。 アプリ開発者は、Android デバイス上でシステム イメージを手動でフラッシュすることに慣れていない可能性があります。これは、通常、愛好家または Android OS 開発者のみが慣れ親しんでいるものであるためです。 GSI をインストールするには、fastboot 経由でシステム イメージをフラッシュする必要があり、そのためには Android Verified Boot を無効にし、ブートローダーのロックを解除する必要があります。 ブートローダーのロックを解除するには、ユーザー データを完全に消去する必要があります。 そして、誰もが知っているように、世の中にはすべての Android デバイスのブートローダーのロックを解除するためのプロセスやガイドがまったく存在するわけではないため、一貫性はありません。 たとえば、Samsung デバイスには fastboot がありませんが、Xiaomi デバイスではブートローダーのロックを解除するためにいくつかのフープを通過する必要があります。 これは便利な混乱ですが、より単純なものに解ける可能性があります。

ここで、動的システム更新が役に立ちます。

GSI をインストールするだけの動的システム更新

Google は、GSI をインストールする現在の方法が完璧なソリューションではないことに気づき、より良いソリューションの開発に取り組み始めました。 Android10では、 Googleが動的システムアップデートのテストを開始、または DSU。 DSU は、fastboot コマンドを使用してシステム イメージをフラッシュする必要がなく、元のインストールを上書きすることなく GSI を一時的にインストールする新しい方法です。 DSU を使用すると、GSI を起動してアプリをテストし、その後、変更されていない元のインストールに簡単に再起動できます。

DSU が元のインストールに手を加えずに GSI をインストールできる理由は、新しいシステムおよびデータ パーティション イメージが作成され、それらのイメージが一時的に保存されるためです。 /data/gsi. これらのイメージは、元のシステム パーティションやデータ パーティションではなく、起動中にマウントされます。 電話機にはこれらの新しい一時イメージ用に追加のストレージ スペースが必要であるため、電話機には動的にサイズ変更可能なパーティションである「論理パーティション」が搭載されている必要があります。 論理パーティションは、Android の新しいユーザー空間パーティショニング システムであり、Android 10 で起動するデバイスに必須です。 デバイスが Android 10 で起動された場合は、DSU を介した GSI のインストールをサポートする必要があります。

Android 10 では、次のことを行う必要があります。 DSU 経由で GSI をインストールする システムプロパティを変更してから、 動的システム更新インストールサービス インテント エクストラとして GSI へのパスを含むインテントを送信します。

このプロセスはなじみがないように思えるかもしれませんが、 fastboot コマンドを使用し、元のインストールを含むすべての面倒な作業に対処します。 拭いた。 DSU を利用するには ADB とインテントに関するある程度の知識が必要ですが、ほとんどのアプリ開発者にとってこれは問題ではありません。 それでも、プロセスをさらに簡素化できない理由はありません。 さらに、DSU 経由で GSI をインストールするには、ブートローダーのロックを解除し、その過程ですべてのユーザー データを消去する必要があるという事実もあります。 この目的を達成するために、Google は GSI インストールの両方の側面を改善するための変更を実装しました。 Android 11 では、GSI をインストールするためにコマンド ラインを使用する必要がまったくなくなりました。 これとは別に、ブートローダーのロックを解除せずに GSI をインストールできるようにしました。

Android 11 の DSU ローダー

DSU Loader は、Android 11 の開発者向けオプションにある新しいツールで、次のことを可能にします。 ダウンロード そして インストール fastboot や ADB コマンドを入力する必要なく、Google から最新の GSI を入手できます。 [設定] 内の [DSU ローダー] オプションをタップするだけで、ダイアログ ボックスに Google から直接提供されるサポートされている GSI のリストが表示されます。 これらのサポートされる GSI は現在の OS とアーキテクチャに基づいているため、OS バージョンよりも新しく、SoC アーキテクチャと一致する GSI のみをインストールできます。 インストールしたい GSI を選択するだけで、Google のサーバーからダウンロードされ、バックグラウンドで自動的にインストールされます。

DSU Loader を使用すると、開発者は GSI をインストールするためにコマンド ラインに触れる必要がありません。 解決すべき問題がまだ 1 つ残っているため、少なくともそれが夢です。

今後の方法

現在、DSU ローダー経由で GSI をインストールするには、ロックが解除されたブートローダーが必要です。 これは試練全体の目的に反するかもしれませんが、こうあるべきではなく、修正されるだろうと私たちは言われています。 Google は、ユーザーがブートローダーのロックを解除しなくても、DSU を通じて Google 署名の GSI を起動できるようにすることを計画しています。 実際、Google はそれを義務付けています すべての Android 10 起動デバイスには Android Verified Boot 公開キーが含まれています Google が署名した Android 10、Android 11、および Android 12 GSI の一部。 デバイスの RAM ディスクに AVB 公開キーを含めると、起動しようとしている GSI が AVB によって拒否されなくなります。 現在の方法ではブートローダーのロックを解除する必要があるのはこのためです。空の vbmeta イメージを vbmeta パーティションにフラッシュすることで、フラッシュしようとしている GSI が拒否されないように AVB を無効にします。 ただし、AVB を無効にすることは、セキュリティ上の大きなリスクとなります。 system/boot/product/vendor パーティションはデバイスにロードできるため、Google はこれを実行したいと考えています。 その要件は取り除きます。

それでは、ブートローダーのロックを解除したりコマンドライン ツールを使用したりせずに、DSU を介して GSI を起動できるのはいつ頃になるのでしょうか? Google が私たちに話したように、初期の Android 11 Developer Preview では、すべてを適切に動作させる前にいくつかの問題を解決する必要があると述べていたので、近いうちに実現することを願っています。 今後は、ブートローダーのロックを解除することなく、DSU 経由で将来の Developer Preview GSI をインストールできるようになります。 おそらく、Android 12 開発者プレビューが利用可能になると、Android 11 の開発者向けオプションの DSU ローダーを使用して完全に起動することもできるようになるでしょう。 アプリ開発者にとって、これは、新しい Android バージョンを実行する物理ハードウェアでアプリケーションをテストする別の方法ができることを意味します。