本頁面由 Cloud Translation API 翻譯而成。

通用系統映像檔

通用系統映像檔 (GSI) 是針對 Android 裝置調整設定的系統映像檔。我們視為「純 Android」實作項目，搭配未經修改的 Android 開放原始碼計畫 (AOSP) 程式碼，讓任何搭載 Android 9 以上版本的 Android 裝置都能順利執行。

GSI 可用於執行 VTS 和 GSI 上的 CTS 測試。將 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 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 移除了與未完全修復的 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 GSI 進行法規遵循測試。這包括以下來自先前 GSI 的重大變更：

system_ext 內容。Android 11 定義了新的分區 system_ext。GSI 會將系統擴充功能內容放在 system/system_ext 資料夾下。
APEXs：GSI 包含已展開和壓縮的 APEX。要使用哪個屬性取決於在執行階段時供應商分區中的系統屬性 ro.apex.updatable。詳情請參閱「設定系統以支援 APEX 更新」。

Android 10 GSI 變更

搭載或更新至 Android 10 的裝置必須使用 Android 10 GSI 進行測試。這包括以下來自先前 GSI 的重大變更：

使用者建構：GSI 有來自 Android 10 的使用者版本。在 Android 10 中，使用者建構的 GSI 可用於 CTS-on-GSI/VTS 相容性測試。詳情請參閱「使用偵錯 RAM 磁碟進行 VTS 測試」。
未剖析的格式。含有 aosp_$arch 目標的 GSI 是使用未剖析格式建構。您可以使用 img2simg 將未剖析的 GSI 轉換為稀疏格式 (如有需要)。
系統以 root 權限執行。舊版 GSI 建構目標 (名為 aosp_$arch_a) 已逐步淘汰。如果裝置是從 Android 8 或 8.1 升級至 Android 10，且使用的是 RAM 磁碟和非系統做為根目錄，請使用舊版 GSI aosp_$arch_ab。升級後的 ramdisk 中的 init 支援使用系統做為根目錄的版面配置的 OEM system.img。
驗證開機程序。使用 GSI 時，您只需解鎖裝置即可。您不需要停用驗證啟動功能。

Android 9 GSI 異動

搭載或已更新至 Android 9 的裝置必須使用 Android 9 GSI 進行法規遵循測試。這包括以下來自先前 GSI 的重大變更：

合併 GSI 和模擬器。GSI 是以模擬器產品的系統映像檔所建構，例如 aosp_arm64 和 aosp_x86。
系統以 root 權限執行。在舊版 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，請參閱「硬體支援的 Keystore」。

下載 GSI

您可以前往 ci.android.com 的 AOSP 持續整合 (CI) 網站，下載預先建構的 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 裝置可能有不同的設計，因此沒有通用指令或一組操作說明，可將 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-bootloader
```
刷新所提供的 vbmeta 時，停用驗證開機程序驗證：
```
$ fastboot --disable-verification flash vbmeta vbmeta.img
```

Reboot:
```
$ 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

postfix _a 應與系統分區的運算單元 ID 相符，如本例中的 system_a。

為 GSI 貢獻心力

Android 歡迎您為 GSI 開發作業做出貢獻。您可以參與以下活動，協助改善 GSI：

建立 GSI 修補程式。DESSERT-gsi 並不是開發分支，且只接受來自 Android 開放原始碼計畫主分支的 cherrypick，因此如要提交 GSI 修補程式，您必須：
1. 將修補程式提交至 Android 開放原始碼計畫 main 分支版本。
2. 將修補程式挑選至 DESSERT-gsi。
3. 請回報錯誤，讓我們審查 cherrypick。
回報 GSI 錯誤或提出其他建議。詳閱「回報錯誤」中的操作說明，然後瀏覽或回報 GSI 錯誤。

提示

使用 GSI 啟動時，導覽列模式會由供應商覆寫設定。您可以在執行階段執行下列 ADB 指令，變更導覽列模式。

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

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