Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

Generic System Image

Generic System Image（GSI）は、Android デバイス用に構成が調整されたシステム イメージです。これは、Android 8.1 以上を実行する Android デバイスが正常に動作する未変更の Android オープンソース プロジェクト（AOSP）コードを備えた純粋な Android 実装と見なされます。

GSI は、VTS テストと CTS-on-GSI テストを実施するために使用されます。Android デバイスのシステム イメージは、GSI に置き換えられた後、ベンダー テストスイート（VTS）と互換性テストスイート（CTS）でテストされます。それによって、デバイスが Android の最新バージョンでベンダー インターフェースを正しく実装していることを確認できます。

GSI を使用するにあたっては、GSI の構成（および許容される差異）、タイプ（Android GSI と従来の GSI）、ベンダー バイナリと VNDK の依存関係についての詳細を、下記のセクションで確認してください。GSI を使用する準備ができたら、デバイス ターゲットに GSI をダウンロードしてビルドし、Android デバイスに GSI をフラッシュします。

GSI 構成と差異

現在の Android GSI の構成は次のとおりです。

  • Treble。GSI には、HIDL ベースのアーキテクチャの変更（Treble とも呼ばれます）の完全なサポートが含まれています。これは Android 8.0 で導入されたもので、HIDL インターフェースに対応しています。GSI は、HIDL ベンダー インターフェースを使用するすべての Android デバイスで使用できます。詳細については、アーキテクチャ リソースをご覧ください。
  • ブート検証。GSI には、vboot 1.0 や AVB などのブート検証ソリューションが含まれていません。Android 9 以前で起動するデバイスに GSI をフラッシュするには、デバイスがブート検証を無効にする方法を備えていることが必要です。
  • ファイル システム。GSI は ext4 ファイル システムを使用します。
  • パーティション レイアウト。GSI は system-as-root のパーティション レイアウトを使用します。

現在の Android GSI には、次の大きな差異が含まれています。

  • CPU アーキテクチャ。さまざまな CPU 命令（ARM、x86 など）と CPU ビット数（32 ビットまたは 64 ビット）のサポート。

Treble コンプライアンス テストの GSI ターゲット

コンプライアンス テストに使用される GSI は、デバイスの起動時の Android バージョンによって決まります。

デバイスのタイプ ビルド ターゲット
Android 10 で起動するデバイス aosp_$arch-user
Android 9 で起動するデバイス aosp_$arch-userdebug
Android 8.0 または Android 8.1 で起動するデバイス aosp_$arch_ab-userdebug

すべての GSI は Android 10 のコードベースからビルドされ、各 CPU アーキテクチャには、対応する GSI バイナリがあります（GSI のビルドにあるビルド ターゲットのリストをご覧ください）。

Android 10 GSI の変更点

Android 10 で起動するデバイスは、Android 10 GSI を使用してコンプライアンス テストを行う必要があります。これには、以下に挙げる従来の GSI からの主な変更点が含まれています。

  • user ビルド。Android 10 から GSI に user ビルドが追加されています。Android 10 では、CTS-on-GSI/VTS コンプライアンス テストに user ビルド GSI を使用できます。詳しくは、デバッグ用 RAM ディスクを使用した VTS テストをご覧ください。
  • 非スパース形式。ターゲットが aosp_$arch の GSI は、非スパース形式でビルドされます。img2simg を使用すると、非スパース形式の GSI を必要に応じてスパース形式に変換できます。
  • system-as-root。aosp_$arch_a という名前の従来の GSI ビルド ターゲットは、段階的に廃止されました。Android 8 または 8.1 から ramdisk と non-system-as-root を使用する Android 10 にアップグレードしたデバイスでは、従来の GSI の aosp_$arch_ab を使用してください。ramdisk のアップグレード版の init は、system-as-root レイアウトを使用する OEM system.img をサポートします。

Android 9 または 10 で起動するデバイスを CTS-on-GSI でテストするには、Android GSI ビルド ターゲットを使用します。

従来の GSI

従来の GSI の名前には、サフィックス _ab が付けられていました（例: aosp_arm64_ab）。従来の GSI は Android 10 ソースツリーからビルドされますが、Android 8 または 8.1 からアップグレードされるデバイス用に以下の下位互換の構成を含んでいます。

  • 32 ビットユーザー空間 + 32 ビット バインダー インターフェース。32 ビット GSI は、引き続き 32 ビット バインダー インターフェースを使用できます。
  • 8.1 VNDK。デバイスでは、付属の 8.1 VNDK を使用できます。
  • ディレクトリのマウント。従来のデバイスの一部では、ディレクトリがマウント ポインタとして使用されます（/bluetooth、/firmware/radio、/persist など）。

Android 8 または 8.1 で起動するデバイスを CTS-on-GSI でテストするには、従来の GSI ビルド ターゲットを使用します。

Android 9 GSI の変更点

Android 9 GSI の主な変更点を以下に示します。

  • GSI とエミュレータの結合。GSI は、aosp_arm64 や aosp_x86 などのエミュレータ製品のシステム イメージからビルドされます。
  • system-as-root。Android の以前のバージョンでは、デバイスが A/B アップデートをサポートしていない場合でも、システム イメージを /system ディレクトリの下にマウントできました。Android 9 では、システム イメージのルートはデバイスのルートとしてマウントされます。
  • 64 ビット バインダー インターフェース。Android 8.x では、32 ビット GSI が 32 ビット バインダー インターフェースを使用していました。Android 9 は 32 ビット バインダー インターフェースをサポートしていないため、32 ビット GSI と 64 ビット GSI は両方とも 64 ビット バインダー インターフェースを使用します。
  • VNDK の適用。Android 8.1 では、VNDK は任意でした。 Android 9 以降では VNDK が必須であるため、BOARD_VNDK_VERSION を設定する必要があります。
  • 互換性のあるシステム プロパティ。Android 9 では、互換性のあるシステム プロパティのアクセス チェックが有効になっています（PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true）。

Android 9 Keymaster の変更点

古いバージョンの Android の場合、Keymaster 3 以下を実装するデバイスでは、実行中のシステムによって報告されるバージョン情報（ro.build.version.release および ro.build.version.security_patch）がブートローダーによって報告されるバージョン情報と一致することを検証する必要がありました。通常、このような情報はブートイメージ ヘッダーから取得されます。

Android 9 以降ではこの要件が変更され、ベンダーが GSI を起動できるようになっています。具体的には、Keymaster は検証を実行しません。GSI によって報告されるバージョン情報とベンダーのブートローダーによって報告されるバージョン情報が一致しない可能性があるためです。Keymaster 3 以下を実装するデバイスでは、検証をスキップするように Keymaster 実装を変更する（または Keymaster 4 にアップグレードする）必要があります。Keymaster の詳細については、ハードウェア式キーストアをご覧ください。

#vendor-binaries-and-vndk-dependencies

Android 10 にアップグレードするデバイスのアップグレード パスは、デバイスで使用されているベンダー バイナリのバージョンと、デバイスをビルドするのに使用される VNDK 関連の構成によって異なります。次の表は、アップグレードされるデバイスの従来の GSI サポートをまとめたものです。

使用事例 ベンダー
バイナリの
バージョン		 BOARD_VNDK_VERSION 従来の GSI の
システム バイナリのバージョン		 従来の GSI のサポート
0 8.0 （すべて） 10 ×
1 8.1 （空） 10 ×
2 8.1 current 10 ○
3 10 current 10 ○

サポートされるユースケースのうち、最も一般的なものは 2 です。このユースケースでは、従来の GSI は、BOARD_VNDK_VERSION が current に設定された状態でビルドされた Android 8.1 を実行するデバイスをサポートします。

ユースケース 1 はサポート対象外です。このユースケースでは、従来の GSI は、ビルドから BOARD_VNDK_VERSION が除外される Android 8.1 を実行するデバイスをサポートしません。このようなデバイスをサポートできないのは、ベンダー バイナリが、従来の GSI には含まれない Android 8.1 の非 VNDK 共有ライブラリに依存しているためです。このようなデバイスに従来の GSI との互換性を持たせるには、次のいずれかを実行する必要があります。

  • BOARD_VNDK_RUNTIME_DISABLE なしで BOARD_VNDK_VERSION を有効にします（ユースケース 2）。

    または

  • ベンダー バイナリを移植 / アップグレードして、Android 10 の共有ライブラリに依存するようにします（ユースケース 3）。

GSI のダウンロード

AOSP 継続的インテグレーション（CI）ウェブサイト（ci.android.com）から、事前ビルド済み GSI をダウンロードできます。ご使用のハードウェア プラットフォーム用の GSI がダウンロードできない場合は、特定のターゲット用に GSI をビルドする方法を次のセクションで参照してください。

GSI のビルド

Android 9 以降、各 Android バージョンの AOSP には DESSERT-gsi という名前の GSI ブランチがあります（たとえば、android10-gsi は Android 10 の GSI ブランチです）。GSI ブランチには、すべてのセキュリティ パッチと GSI パッチが適用された Android のコンテンツが含まれます。

GSI をビルドするには、Android ソースツリーを GSI ブランチからダウンロードし、GSI ビルド ターゲットを選択して、Android ソースツリーを設定します。以下のビルド ターゲット表を使用して、目的のデバイスに合った GSI バージョンを確認してください。ビルドが完了すると、GSI はシステム イメージ（つまり system.img）になり、出力フォルダ out/target/product/generic_arm64 に表示されます。また、ビルドは vbmeta.img も出力します。これを使用して、Android Verified Boot を使用するデバイスで、ブート検証を無効にできます。

たとえば、GSI ブランチ android10-gsi で GSI ビルド ターゲット aosp_arm64-userdebug をビルドするには、以下のコマンドを実行します。

$ repo init -u https://android.googlesource.com/platform/manifest -b android10-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch aosp_arm64-userdebug
$ make -j4

Android GSI ビルド ターゲット

Android 9 以降で起動するデバイス向けの GSI ビルド ターゲットを以下に示します。アーキテクチャ間の差異が少ないため、Android 10 には 4 つの GSI プロダクトしか含まれていません。

GSI 名 CPU アーキテクチャ バインダー インターフェースのビット数 system-as-root ビルド ターゲット
aosp_arm ARM 64 ○ aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 ○ aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 x86 64 ○ aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 ○ aosp_x86_64-user
aosp_x86_64-userdebug

従来の GSI ビルド ターゲット

Android 8.0 または 8.1 から Android 10 にアップグレードするデバイス向けの従来の GSI ビルド ターゲットを以下に示します。Android 10 の GSI 名と区別するため、従来の GSI の名前にはサフィックス _ab が付いています。

GSI 名 CPU アーキテクチャ バインダー インターフェースのビット数 system-as-root ビルド ターゲット
aosp_arm_ab ARM 32 ○ aosp_arm_ab-userdebug
aosp_arm_64b_ab ARM 64 ○ aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 ○ aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 ○ aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 ○ aosp_x86_64_ab-userdebug

GSI をフラッシュするための要件

Android デバイスにはさまざまな設計が存在するため、GSI をフラッシュしてすべてのデバイスに適用することができる汎用的なコマンドや手順はありません。明示的なフラッシュの手順については、Android デバイスのメーカーに問い合わせてください。 一般的なガイドラインとして、次の手順を使用します。

  1. デバイスが以下の要件を満たしていることを確認します。
    • Treble 対応
    • デバイスのロックを解除する方法（fastboot でフラッシュできるようにするため）
    • ブート検証（vboot 1.0 や AVB など）を無効にする方法
    • fastboot でフラッシュできるようにするためのロック解除状態（最新バージョンの fastboot を確実に入手するには、Android ソースツリーからビルドします）
  2. ブート検証を無効にします。
  3. 現在のシステム パーティションを消去し、GSI をシステム パーティションにフラッシュします。
  4. ユーザーデータをワイプし、他の必要なパーティション（ユーザーデータ パーティションやシステム パーティションなど）からデータをクリアします。
  5. デバイスを再起動します。

たとえば、GSI を任意の Pixel デバイスにフラッシュするには、次の手順に従います。

  1. fastboot モードで起動し、ブートローダーのロックを解除します。vbmeta.img をフラッシュすることにより、確認付きブート（AVB）を無効にします。 
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  2. また、fastbootd に対応しているデバイスでは、次のコマンドを使用して fastbootd で起動する必要があります。
    $ fastboot reboot fastboot
  3. GSI を消去し、システム パーティションにフラッシュします。 
    $ fastboot erase system
$ fastboot flash system system.img
  4. ユーザーデータをワイプし、他の必要なパーティション（ユーザーデータ パーティションやシステム パーティションなど）からデータをクリアします。 
    $ fastboot -w
  5. 再起動します。 
    $ fastboot reboot
システム パーティションが小さい Android 10 デバイスでは、GSI のフラッシュ時に次のエラー メッセージが表示されることがあります。
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
プロダクト パーティションを削除し、システム パーティションの空き容量を増やすには、次のコマンドを使用します。これにより空き容量が増え、GSI をフラッシュできるようになります。 
$ fastboot delete-logical-partition product_a
接尾辞 _a は、この例の system_a のように、システム パーティションのスロット ID と一致する必要があります。

GSI への貢献

Android は GSI 開発への貢献を歓迎します。以下の行為を通じて、GSI の改善にご協力いただけます。

  • GSI パッチを作成する。DESSERT-gsi は開発ブランチではなく、AOSP master ブランチから選ばれたもののみを受け入れています。そのため、GSI パッチを提出するには、次のことを行う必要があります。
    1. パッチを AOSP master ブランチに提出します。
    2. DESSERT-gsi 用にパッチを選びます。
    3. 選んだパッチの審査を受けるため、バグを報告します。
  • GSI バグを報告するまたはその他の提案を行う。バグの報告手順を確認したうえで、GSI バグを参照または報告します。

ヒント

adb を使用してナビゲーション バーのモードを変更する

GSI を使って起動する場合、ナビゲーション バーのモードはベンダーのオーバーライドによって設定されます。ナビゲーション バーのモードを変更するには、ランタイム時に次の adb コマンドを実行します。 

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

ここで、mode に threebutton、twobutton、gestural などを指定できます。