Generic System Image

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

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

注: この記事では、Android OEM と ROM デベロッパー向けの GSI トピックについて説明します。Android アプリのデベロッパーは、developer.android.com で、GSI に関するデベロッパー向けの詳細情報をご覧ください。

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

GSI 構成と差異

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

• Treble。GSI には、AIDL インターフェースや HIDL インターフェースのサポートを含め、AIDL / HIDL ベースのアーキテクチャの変更（Treble とも呼ばれます）の完全なサポートが含まれています。GSI は、AIDL / HIDL ベンダー インターフェースを使用するすべての Android デバイスで使用できます（詳しくは、アーキテクチャ リソースをご覧ください）。
• ファイル システム。GSI は ext4 ファイル システムを使用します。

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

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

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

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

デバイスのタイプ	ビルド ターゲット
Android 15 で起動するデバイス	gsi_$arch-user（署名済み）
Android 14 で起動するデバイス	gsi_$arch-user（署名済み）
Android 13 で起動するデバイス	gsi_$arch-user（署名済み）
Android 12L で起動するデバイス	gsi_$arch-user（署名済み）
Android 12 で起動するデバイス	gsi_$arch-user（署名済み）
Android 11 で起動するデバイス	gsi_$arch-user（署名済み）

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

Android 12 GSI の変更点

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

• ターゲット名。コンプライアンス テストの GSI ターゲット名は gsi_$arch に変更されました。ターゲット名が aosp_$arch の GSI は Android アプリ デベロッパー向けに保持されています。ベンダー インターフェースのテスト用のテストプラン CTS-on-GSI も縮小されています。
• 以前の GSI のサポートは終了します。GSI 12 は、完全に Treble に対応していない Android 8.0 または 8.1 のデバイスに対応する回避策を削除しました。
• Userdebug SEPolicy。GSI gsi_$arch には userdebug_plat_sepolicy.cil が含まれます。OEM 固有の vendor_boot-debug.img または boot-debug.img をフラッシュする際、/system/bin/init は GSI system.img から userdebug_plat_sepolicy.cil を読み込みます。詳しくは、デバッグ用 RAM ディスクを使用した VTS テストをご覧ください。

Android 11 GSI の変更点

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

• system_ext のコンテンツ。Android 11 は新しいパーティション system_ext を定義しています。 GSI のシステム拡張機能のコンテンツはフォルダ system/system_ext に収められています。
• APEX。GSI には、フラット形式と圧縮形式の両方の APEX が含まれます。 どちらを使用するかは、実行時のベンダー パーティション内のシステム プロパティ ro.apex.updatable によって決まります。詳しくは、APEX アップデートをサポートするシステムの設定をご覧ください。

Android 10 GSI の変更点

Android 10 で起動または 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 をサポートします。
• ブート検証。GSI を使用するのに必要なのは、デバイスのロックを解除することだけです。 ブート検証を無効にする必要はありません。

Android 9 GSI の変更点

Android 9 で起動または Android 9 に更新されたデバイスは、コンプライアンス テストに Android 9 GSI を使用する必要があります。これには、以下に挙げる以前の 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 の詳細については、ハードウェア式キーストアをご覧ください。

GSI をダウンロードする

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

GSI のビルド

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

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

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

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

Android GSI ビルド ターゲット

Android 9 以降で起動するデバイス向けの GSI ビルド ターゲットを以下に示します。

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

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

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

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

たとえば、GSI を任意の Google Pixel にフラッシュするには、次の手順を行います。

1. fastboot モードで起動し、ブートローダーのロックを解除します。
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 main ブランチから選ばれたもののみを受け入れています。そのため、GSI パッチを提出するには、次のことを行う必要があります。
  1. パッチを AOSP main ブランチに提出します。
  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 などを指定できます。