通用系統映像檔 (GSI) 是經過調整設定的系統映像檔,適用於 Android 裝置。這項實作項目被視為「純 Android」,具備未經修改的 Android 開放原始碼計畫 (AOSP) 程式碼,可在執行 Android 9 以上版本的任何 Android 裝置上順利執行。
GSI 用於執行 VTS 和 CTS-on-GSI 測試。Android 裝置的系統映像檔會替換為 GSI,然後使用供應商測試套件 (VTS) 和 Compatibility Test Suite (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 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_$arch
。Android 應用程式開發人員可使用目標名稱為「aosp_$arch
」的 GSI。測試計畫CTS-on-GSI
也會減少,以測試供應商介面。 - 舊版 GSI 已淘汰。GSI 12 會移除因應 Android 8.0 或 8.1 裝置的權宜措施,這些裝置並未完全 Treblized。
- Userdebug 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
。詳情請參閱「使用偵錯 Ramdisk 進行 VTS 測試」。
Android 11 GSI 變更
如果裝置搭載 Android 11 或更新至 Android 11,就必須使用 Android 11 GSI 進行相容性測試。包括下列重大異動:
- system_ext 內容。Android 11 定義了新的分區
system_ext
。 GSI 會將系統擴充功能內容放在system/system_ext
資料夾下。 - APEXes。GSI 包含扁平化和壓縮的 APEX。
要使用哪一個,取決於執行階段供應商分區中的系統屬性
ro.apex.updatable
。詳情請參閱「 設定系統以支援 APEX 更新」。
Android 10 GSI 變更
如果裝置搭載 Android 10 或更新至 Android 10,就必須使用 Android 10 GSI 進行相容性測試。包括下列重大異動:
- 使用者版本。GSI 具有 Android 10 的使用者版本。在 Android 10 中,使用者建構 GSI 可用於 CTS-on-GSI/VTS 相容性測試。詳情請參閱「使用偵錯 Ramdisk 進行 VTS 測試」。
- 未稀疏格式。GSI with targets
aosp_$arch
are built with unsparsed format. 如有需要,您可以使用img2simg
將未稀疏化的 GSI 轉換為稀疏格式。 - 以系統做為根目錄。名為
aosp_$arch_a
的舊版 GSI 建構目標已淘汰。如果裝置是從 Android 8 或 8.1 升級至 Android 10,且使用 ramdisk 和非系統即根目錄,請使用舊版 GSIaosp_$arch_ab
。 升級後的 ramdisk 中的init
支援 OEM system.img,並採用 system-as-root 版面配置。 - 驗證開機程序。使用 GSI 時,你只需要解鎖裝置。 不需要停用驗證開機程序。
Android 9 GSI 變更
如果裝置搭載 Android 9 或更新至 Android 9,就必須使用 Android 9 GSI 進行相容性測試。包括下列重大異動:
- 合併 GSI 和模擬器。GSI 是以模擬器產品的系統映像檔建構而成,例如
aosp_arm64
和aosp_x86
。 - 以系統做為根目錄。在舊版 Android 中,不支援 A/B 更新的裝置可以在
/system
目錄下掛接系統映像檔。在 Android 9 中,系統映像檔的根目錄會掛接為裝置的根目錄。 - 64 位元繫結器介面。在 Android 8.x 中,32 位元 GSI 使用 32 位元繫結器介面。Android 9 不支援 32 位元繫結器介面,因此 32 位元和 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 的詳細資訊,請參閱「硬體支援的 Keystore」。
下載 GSI
您可以從 AOSP 持續整合 (CI) 網站 (ci.android.com) 下載預建 GSI。如果無法下載適用於硬體平台的 GSI 類型,請參閱下一節,瞭解如何為特定目標建構 GSI。
建構 GSI
從 Android 9 開始,每個 Android 版本在 AOSP 上都有一個名為 DESSERT-gsi
的 GSI 分支 (例如 android12-gsi
是 Android 12 的 GSI 分支)。GSI 分支版本包含 Android 內容,並套用所有安全性修補程式和 GSI 修補程式。
如要建構 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 架構 | 繫結器介面位元數 | 系統即根目錄 | 建立目標 |
---|---|---|---|---|
gsi_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 裝置的設計可能不同,因此沒有適用於所有裝置的通用指令或一組指令。如需明確的刷機操作說明,請洽詢 Android 裝置製造商。請按照下列步驟操作:
- 確認裝置符合下列條件:
- Treblized
- 解鎖裝置的方法 (以便使用
fastboot
刷機) - 解鎖狀態,可透過
fastboot
刷機 (為確保您擁有最新版fastboot
,請從 Android 來源樹狀結構建構)。
- 清除目前的系統分區,然後將 GSI 刷入系統分區。
- 清除使用者資料,並清除其他必要分割區的資料 (例如使用者資料和系統分割區)。
- 重新啟動裝置。
舉例來說,如要將 GSI 刷入任何 Pixel 裝置,請按照下列步驟操作:
- 啟動至
fastboot
模式,然後解鎖系統啟動載入程式。 - 支援
fastbootd
的裝置也必須啟動fastbootd
,方法如下:$ fastboot reboot fastboot
- 清除並將 GSI 刷入系統分區:
$ fastboot erase system $ fastboot flash system system.img
- 如果裝置支援 Android Virtual Framework,請刷入受保護的虛擬機器韌體:
$ fastboot flash pvmfw pvmfw.img
- 清除使用者資料,並清除其他必要磁碟分割區的資料 (例如使用者資料和系統磁碟分割區):
$ fastboot -w
- 重新啟動並返回系統啟動載入程式:
$ fastboot reboot-bootloader
- 在刷入提供的 vbmeta 時,停用驗證開機程序驗證:
$ fastboot --disable-verification flash vbmeta vbmeta.img
- Reboot:
$ fastboot reboot
Resizing 'system_a' FAILED (remote: 'Not enough space to resize partition') fastboot: error: Command failed
$ fastboot delete-logical-partition product_a
_a
應與系統分割區的 slot ID 相符,例如本例中的 system_a
。
為 GSI 貢獻心力
Android 歡迎您為 GSI 開發作業貢獻心力。您可以透過下列方式參與 GSI 計畫,協助我們提升服務品質:
- 建立 GSI 修補程式。
DESSERT-gsi
「不是」開發分支版本,只接受來自 Android 開放原始碼計畫最新發布分支版本 (android16-release
) 的 Cherrypick,因此如要提交 GSI 修補程式,請按照下列步驟操作:- 將修補程式提交至 Android 開放原始碼計畫
android16-release
分支版本。 - 將修補程式挑選至
DESSERT-gsi
。 - 提出錯誤報告,要求審查 Cherrypick。
- 將修補程式提交至 Android 開放原始碼計畫
- 回報 GSI 錯誤或提出其他建議。請參閱「回報錯誤」一文中的指示,然後瀏覽或回報 GSI 錯誤。
訣竅
使用 adb 變更導覽列模式
使用 GSI 開機時,導覽列模式會由供應商覆寫設定。您可以在執行階段執行下列 adb 指令,變更導覽列模式。
adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode
其中 mode 可以是 threebutton
、twobutton
、gestural
等。