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-useraosp_arm-userdebug |
aosp_arm64 |
ARM64 | 64 | ○ | aosp_arm64-useraosp_arm64-userdebug |
aosp_x86 |
x86 | 64 | ○ | aosp_x86-useraosp_x86-userdebug |
aosp_x86_64 |
x86-64 | 64 | ○ | aosp_x86_64-useraosp_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 デバイスのメーカーに問い合わせてください。 一般的なガイドラインとして、次の手順を使用します。
- デバイスが以下の要件を満たしていることを確認します。
- ブート検証を無効にします。
- 現在のシステム パーティションを消去し、GSI をシステム パーティションにフラッシュします。
- ユーザーデータをワイプし、他の必要なパーティション（ユーザーデータ パーティションやシステム パーティションなど）からデータをクリアします。
- デバイスを再起動します。
たとえば、GSI を任意の Pixel デバイスにフラッシュするには、次の手順に従います。
fastbootモードで起動し、ブートローダーのロックを解除します。また、fastbootdに対応しているデバイスでは、次のコマンドを使用してfastbootdで起動する必要があります。$ fastboot reboot fastboot
vbmeta.imgをフラッシュすることにより、ブート検証（AVB）を無効にします。$ fastboot --disable-verification flash vbmeta vbmeta.img
- GSI を消去し、システム パーティションにフラッシュします。
$ fastboot erase system $ fastboot flash system system.img
- ユーザーデータをワイプし、他の必要なパーティション（ユーザーデータ パーティションやシステム パーティションなど）からデータをクリアします。
$ fastboot -w
- 再起動します。
$ fastboot reboot
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 の改善にご協力いただけます。