通用核心映像檔 (GKI) 發布程序

本頁面說明 GKI 的發布方式，包括每季和頻外緊急發布。本頁旨在為原始設備製造商 (OEM) 提供指南，說明如何取得 GKI，以及頻外緊急修正程序。原始設備製造商 (OEM) 也可以參閱「GKI 開發」，進一步瞭解如何與 Android 核心團隊合作，針對自家產品最佳化 GKI 核心。

GKI 發布頻率

KMI 凍結後，GKI 會每季發布一次。

原始設備製造商 (OEM) 的 GKI 版本效期

原始設備製造商可以使用最近發布的 Android GKI。只要符合 Android 安全性公告 (ASB) 的長期支援 (LTS) 核心規定，原始設備製造商 (OEM) 就能推出通過 GKI 認證的版本。

16 KB GKI 版本

GKI 發布團隊會處理 16 KB GKI 版本，採用與 4 KB GKI 版本相同的每季發布頻率、資格測試和重新發布程序：

• 支援的分支版本：
  • android15-6.6 (2026 年 1 月起)
  • android16-6.12 (2026 年 3 月起)
  • android17-6.18 (2026 年 6 月起)
• 建構同位元和認證：16 KB GKI 二進位檔與對應的 4 KB GKI 版本使用相同的來源標記和核心建構 ID。在 2027 年前，android15-6.6、android16-6.12 和 android17-6.18 發布子版本頁面的「16 KB release build」分頁，會提供未經認證的 16 KB GKI 發布二進位檔。您不需要同時更新 4 KB 和 16 KB 核心，但建議這麼做。
• 依需求重新編譯：使用與 4 KB 版本相同的重新編譯要求程序和表單，要求重新編譯 16 KB GKI。

每季認證版本

GKI 每季版本包含經過測試的 boot.img，其中含有 Google 插入的憑證，可證明二進位檔是根據已知的原始碼基準建構而成。

每個季度，我們會在檢查截止日期後，選取 GKI 季度候選版本 (未通過認證)。選取每季候選版本後，當月版本將不再接受新的變更。在凍結期內，只能修正導致測試失敗的錯誤。候選版會經過品質查驗 (如 GKI 資格認證一節所述)，確認 GSI+GKI 版本在參考裝置和 Cuttlefish 上通過法規遵循測試。

圖 1. GKI 發布時間表

GKI 資格條件

如何取得建構構件

原始設備製造商 (OEM) 可從 ci.android.com 取得所有版本的構件。

如要進一步瞭解 CI，包括測試結果，請前往 Android 持續整合資訊主頁。

常見問題

以下是 GKI 發布程序相關常見問題。

是否可以根據已發布的 GKI 建構新的 GKI 二進位檔？

可以，這稱為「重新發布」。只要發布的 GKI 建構版本 (要求重製的對象) 符合 Android 安全性公告 (ASB) 中的 LTS 規定，系統就支援重製程序。

可以重現 GKI 二進位檔嗎？

可以，範例如下：

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

如要重現範例，請下載 manifest_$id.xml 並執行下列指令：

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

您可以從 out/.../dist 擷取 GKI 構件副本。

GKI 二進位檔 (包括緊急修正程式) 是否已在最新程式碼集上建構？

否。Respin 僅包含所選季度認證核心之上的修補程式。這些重新發布的版本包含所有會阻礙啟動的錯誤修正，這些錯誤是由 OEM 使用對應的基本季度版本，在任何指定時間之前回報。請參閱以下範例，瞭解這類情況的發生方式。

• OEM1 和 OEM2 決定使用 2021 年 11 月的 GKI 二進位檔版本。
• OEM1 和 OEM2 發現需要修補程式才能支援的問題。這些修補程式可能相同，也可能不同。
• 2021 年 11 月二進位檔之上的重新發布版本，包含 OEM1 和 OEM2 在重新發布期間回報的啟動阻礙修正，但僅此而已。
• 第二點提到的問題也包含在後續的 GKI 季度版本中。

10 月重新發布的版本包含所有 OEM 提交的修補程式，但其他 OEM 修補程式會影響我們，因為這些修補程式尚未針對我們的產品進行專門測試。是否可以只納入我們的修補程式？

這是不可能的。個別原始設備製造商的重新旋轉路徑無法擴充。相反地，GKI 團隊會仔細檢查進入重新建構作業的每項變更，並在建立新版本之前，使用所有可用的硬體測試變更。如果 GKI 團隊發現問題是 OEM、裝置或型號專屬，GKI 團隊可以驗證變更所新增的程式碼是否只在受影響的裝置、型號或 SKU 上執行。

統一重新發布的主要好處是，使用相同版本基礎的每部裝置都能互相受益，尤其是當他們發現的錯誤是通用的，且適用於所有使用者。在電信業者測試中發現的核心核心錯誤，就是這個概念的具體例子。

Google 是否會在某些情況下，提供 OEM 修補程式和問題情境的具體資訊，讓 OEM 評估在產品中實作修補程式的影響和風險？

在 GKI 團隊瞭解問題並收集所有詳細資料之前，Google 絕不會將變更新增至重新旋轉建構版本。您可以在變更記錄 (提交訊息) 中看到這點。Google 不會透露受影響的具體裝置，但原始設備製造商 (OEM) 隨時可以在變更記錄中找到問題說明和解決方案。