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

本頁面說明 GKI 的發布方式，包括每週、每季和頻外緊急發布。本文件的目標是為原始設備製造商提供指引，說明如何取得 GKI，以及如何進行頻外緊急修正。原始設備製造商也可以參閱 GKI 開發，進一步瞭解如何與 Android 核心團隊合作，為自家產品最佳化 GKI 核心。

GKI 發布頻率

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

OEM 的 GKI 建構有效性

原始設備製造商可以使用最近發布的 Android GKI。只要符合 Android 安全性公告中的 LTS 要求，OEM 就能使用 GKI 認證版本啟動裝置。

每季認證版本

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

每個季度，系統會在檢查截止日期後選取 GKI 季度候選版本 (未通過認證)，通常是該月的第二個每週建構版本。選取每季候選版本後，系統不會接受當月發布版本的新變更。在封閉期內，我們只會修正導致測試失敗的錯誤。如「GKI 資格」一節所述，候選版本會經過品質保證，確保 GSI+GKI 建構版本在參考裝置和 Cuttlefish 上通過相容性測試。

圖 1. GKI 發布時間表

GKI 資格

如何取得建構成果

如要取得所有版本的構件，請前往 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 團隊發現問題只會影響特定 OEM、裝置或型號，可以確保變更新增的程式碼只會在受影響的裝置、型號或 SKU 上執行。

統一重新發布的主要優點是，使用相同發布版本的裝置都能互相受益，特別是如果發現的錯誤是通用錯誤，適用於所有使用者。在電信業者測試中發現的核心核心錯誤，就是這個概念的具體例子。

Google 是否會在特定情況下提供有關 OEM 修補程式和問題情境的具體資訊，讓 OEM 評估在產品中導入修補程式的影響和風險？

Google 必須先瞭解問題並收集所有詳細資料，才會將變更加入重新發布的建構版本。這會顯示在變更記錄中 (提交訊息)。Google 不會揭露受影響的具體裝置，但原始設備製造商 (OEM) 一律可以在變更記錄中找到問題說明和解決方案。