通用系統映像 (GSI) 是針對 Android 裝置調整配置的系統映像。它被認為是純 Android實現,具有未經修改的 Android 開源專案 (AOSP) 程式碼,任何運行 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位元)。
Treble 合規性測試的 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
將從 GSIsystem.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 開始具有使用者版本。有關詳細信息,請參閱使用 Debug Ramdisk 進行 VTS 測試。
- 非稀疏格式。目標為
aosp_$arch
的 GSI 是使用非稀疏格式建構的。如有必要,您可以使用img2simg
將非稀疏 GSI 轉換為稀疏格式。 - 系統作為根。名為
aosp_$arch_a
的舊版 GSI 建置目標已被淘汰。對於使用 ramdisk 且非系統為 root 從 Android 8 或 8.1 升級到 Android 10 的設備,請使用舊版 GSIaosp_$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 位元 Binder 介面。 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_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 建置目標
以下 GSI 建置目標適用於在 Android 9 或更高版本上啟動的裝置。
GSI名稱 | CPU架構 | Binder介面位數 | 系統作為root | 建立目標 |
---|---|---|---|---|
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 裝置製造商以取得明確的刷新說明。使用以下步驟作為一般準則:
- 確保設備具有以下功能:
- 三重化
- 一種解鎖裝置的方法(以便可以使用
fastboot
對其進行刷新) - 解鎖狀態,使其可透過
fastboot
進行刷新(為確保您擁有最新版本的fastboot
,請從 Android 原始碼樹建置它。)
- 擦除目前系統分割區,然後將 GSI 刷新到系統分割區。
- 清除使用者資料並清除其他必要分區(例如使用者資料和系統分區)中的資料。
- 重新啟動設備。
例如,要將 GSI 快閃記憶體到任何 Pixel 裝置:
- 啟動至
fastboot
模式並解鎖啟動載入程式。 - 支援
fastbootd
裝置也需要透過以下方式啟動到fastbootd
:$ fastboot reboot fastboot
- 擦除 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
應與系統分區的插槽 ID 匹配,例如本範例中的system_a
。為 GSI 做出貢獻
Android 歡迎您為 GSI 開發做出貢獻。您可以透過以下方式參與並協助改進 GSI:
- 建立 GSI 補丁。
DESSERT -gsi
不是開發分支,僅接受來自 AOSP 主分支的cherrypicks,因此提交 GSI 補丁,您必須:- 將補丁提交到AOSP
main
分支。 - 精挑細選
DESSERT -gsi
的補丁。 - 提交錯誤以讓cherrypick 得到審核。
- 將補丁提交到AOSP
- 報告 GSI 錯誤或提出其他建議。查看報告錯誤中的說明,然後瀏覽或歸檔GSI 錯誤。
尖端
使用adb更改導覽列模式
使用 GSI 啟動時,導覽列模式由供應商覆蓋配置。您可以透過在執行時執行以下 adb 命令來變更導覽列模式。
adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode
其中mode可以是threebutton
、 twobutton
、 gestural
等。