通用系統映像

通用系統映像 (GSI) 是針對 Android 設備調整配置的系統映像。它被認為是具有未經修改的 Android 開源項目 (AOSP) 代碼的純 Android實現，任何運行 Android 9 或更高版本的 Android 設備都可以成功運行。

GSI 用於運行 VTS 和 CTS-on-GSI 測試。將 Android 設備的系統映像替換為 GSI，然後使用供應商測試套件 (VTS)和兼容性測試套件 (CTS)進行測試，以確保設備使用最新版本的 Android 正確實現供應商接口。

要開始使用 GSI，請查看以下部分以了解有關GSI 配置（和允許的差異）和類型的詳細信息。當您準備好使用 GSI 時，為您的設備目標下載並構建 GSI ，然後將 GSI 閃存到 Android 設備。

GSI 配置和差異

當前的 Android GSI 有以下配置：

  • 高音。 GSI 包括對基於 AIDL/HIDL 的架構更改（也稱為Treble ）的完全支持，包括對AIDL 接口和HIDL 接口的支持。您可以在任何使用 AIDL/HIDL 供應商接口的 Android 設備上使用 GSI。 （有關更多詳細信息，請參閱架構資源。）
  • 文件系統。 GSI 使用 ext4 文件系統。

當前的 Android GSI 包括以下主要差異：

  • CPU 架構。支持不同的 CPU 指令（ARM、x86 等）和 CPU 位數（32 位或 64 位）。

高音一致性測試的 GSI 目標

用於合規性測試的 GSI 由設備啟動時使用的 Android 版本決定。

設備類型構建目標
搭載 Android 12 的設備gsi_$arch-user （簽名）
搭載 Android 11 的設備gsi_$arch-user （簽名）
搭載 Android 10 的設備gsi_$arch-user （簽名）
搭載 Android 9 的設備gsi_$arch-userdebug

所有 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 刪除了適用於未完全 Treblized 的 Android 8.0 或 8.1 設備的解決方法。
  • 用戶調試 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 。有關詳細信息，請參閱使用 Debug Ramdisk 進行 VTS 測試。

Android 11 GSI 更改

搭載 Android 11 或更新至 Android 11 的設備必須使用 Android 11 GSI 進行合規性測試。這包括與早期 GSI 相比的以下主要變化：

  • system_ext 內容。 Android 11 定義了一個新的分區system_ext 。 GSI 將系統擴展內容放在文件夾system/system_ext下。
  • 頂點。 GSI 包含扁平化和壓縮的 APEX。使用哪一個由運行時供應商分區中的系統屬性ro.apex.updatable確定。有關詳細信息，請參閱配置系統以支持 APEX 更新。

Android 10 GSI 更改

搭載 Android 10 或更新至 Android 10 的設備必須使用 Android 10 GSI 進行合規性測試。這包括與早期 GSI 相比的以下主要變化：

  • 用戶構建。 GSI 具有來自 Android 10 的用戶構建。在 Android 10 中，用戶構建 GSI 可用於 CTS-on-GSI/VTS 合規性測試。有關詳細信息，請參閱使用 Debug Ramdisk 進行 VTS 測試。
  • 非稀疏格式。以aosp_$arch為目標的 GSI 使用非稀疏格式構建。如有必要，您可以使用img2simg將未稀疏的 GSI 轉換為稀疏格式。
  • 系統作為根。名為aosp_$arch_a的舊版 GSI 構建目標已被淘汰。對於從 Android 8 或 8.1 升級到具有 ramdisk 和非系統作為 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 。
  • 系統作為根。在之前的 Android 版本中，不支持 A/B 更新的設備可以將系統映像掛載到/system目錄下。在 Android 9 中，系統映像的根目錄作為設備的根目錄掛載。
  • 64 位活頁夾接口。在 Android 8.x 中，32 位 GSI 使用 32 位綁定器接口。 Android 9 不支持 32 位 binder 接口，因此 32 位 GSI 和 64 位 GSI 都使用 64 位 binder 接口。
  • 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，請通過從 GSI 分支下載並選擇 GSI 構建目標來設置 Android 源代碼樹。使用下面的構建目標表來確定您設備的正確 GSI 版本。構建完成後，GSI 是系統映像（即system.img ）並出現在輸出文件夾out/target/product/ generic_arm64中。

例如，要在 GSI 分支android12-gsi gsi 上構建 GSI 構建目標gsi_arm64-userdebug 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 構建目標

以下 GSI 構建目標適用於在 Android 9 或更高版本上啟動的設備。

GSI 名稱CPU拱門Binder 接口位數系統為根構建目標
gsi_arm手臂64是gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64是gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64是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. 確保設備具有以下內容：
    • 高音
    • 一種解鎖設備的方法（因此可以使用fastboot它們）
    • 解鎖狀態，使其可通過fastboot （為確保您擁有最新版本的fastboot ，請從 Android 源代碼樹構建它。）
  2. 擦除當前系統分區，然後將 GSI 刷入系統分區。
  3. 擦除用戶數據並清除其他必要分區中的數據（例如，用戶數據和系統分區）。
  4. 重新啟動設備。

例如，要將 GSI 閃存到任何 Pixel 設備：

  1. 引導至快速fastboot模式並解鎖引導加載程序。
  2. 支持fastbootd的設備也需要通過
    $ fastboot reboot fastboot
    啟動到fastbootd
  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應該與系統分區的插槽 id 匹配，例如本例中的system_a 。

為 GSI 做出貢獻

Android 歡迎您為 GSI 開發做出貢獻。您可以通過以下方式參與並幫助改進 GSI：

  • 創建 GSI 補丁。 DESSERT -gsi不是開發分支，只接受來自 AOSP 主分支的櫻桃選擇，因此要提交 GSI 補丁，您必須：
    1. 將補丁提交到AOSP master分支。
    2. Cherrypick 補丁到DESSERT -gsi 。
    3. 提交一個錯誤以審查cherrypick。
  • 報告 GSI 錯誤或提出其他建議。查看報告錯誤中的說明，然後瀏覽或歸檔GSI 錯誤。

尖端

使用 adb 更改導航欄模式

使用 GSI 引導時，導航欄模式由供應商覆蓋配置。您可以通過在運行時運行以下 adb 命令來更改導航欄模式。

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

其中mode可以是threebutton 、 twobutton 、 gestural等。