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

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

GKI 發布頻率

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

OEM 的 GKI 建構有效性

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

每週開發版本

變更合併後，您可透過 Android CI 自助取得 GKI 二進位檔。每週建構版本不會經過認證，但可用於開發和測試的基準。每週建構版本無法用於為使用者建構生產裝置。

每季認證版本

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

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

圖 1. GKI 發布時間表

緊急重新發布程序

「重新衍生」是指在公開發布 GKI 核心後，重新合併、重建、重新測試及重新認證二進位檔的程序。在下列情況下，您可以要求重新發布已認證的二進位檔：

• 如要更新符號清單，請按照下列步驟操作。
• 修正錯誤，包括在電信業者實驗室核准期間發現的錯誤。
• 如要新增供應商掛鉤。
• 將修補程式套用至現有功能。
• 如要套用安全性修補程式 (6 個月後)。

在發布分支版本後的 6 個月內，安全性修補程式會自動合併至該分支版本。6 個月後，您必須要求重製，才能將安全性修補程式套用至分支版本。

Respin 要求指南

要求重新生成前，請注意下列事項：

• 只有在季度版本首次公開發布後，才能在發布分支版本上重新發布。

• 只有在初始公開發布後最多六個月內，才能針對特定發布分支提出重製要求。六個月後，只有在 Android 安全性公告提及安全性修補程式時，分支版本才符合重製資格。

• 如果 LTS 需求 (由 Android 安全性公告定義) 導致分支版本不相容，該分支版本就會遭到淘汰。系統不會接受已淘汰分支的重製要求。特定 GKI 發布分支版本的淘汰日期，會列在「版本」下方的季度 GKI 發布版本建構注意事項中。為利於日後規劃，LTS 需求每年會在 5 月和 11 月更新。舉例來說，2024 年 5 月 1 日後，android12-5.10-2023-07 分支 (5.10.177) 不支援重新旋轉，因為 android12-5.10-2023-07 分支 (5.10.177) 不符合 ASB-2024-05 的 LTS 規定。

• 只有在需要緊急修正錯誤、更新符號清單，或是套用修補程式來修正現有功能時，才適用於重新發布。

• 所有要併入季發行分支的修補程式，都必須先併入主要的 GKI 開發分支。舉例來說，如果 android12-5.10-2022-09 的重新旋轉需要修補程式，則必須先將該修補程式合併至 android12-5.10。

• 您必須從主要 GKI 開發分支挑選修補程式，並將修補程式上傳至每季發布分支。

• 在重新旋轉要求中，您必須為要求指派優先順序 (緊急程度)。這項優先順序可協助 GKI 團隊及時為合作夥伴提供更完善的服務。 如需專人提供立即協助，請將優先順序標示為 P0。如果是 P0 和 P1 要求，您也必須說明緊急程度。下表列出錯誤優先順序和解決時間 (ESRT) 的對應關係：

  優先順序	ESRT
  P0	2 個工作天
  P1	5 個工作天
  P2	10 個工作天
  P3	15 個工作天

• 每個發行分支都必須分別提交重新旋轉要求。舉例來說，如果 android12-5.10-2022-08 和 android12-5.10-2022-09 都需要重新審查，您就必須建立兩項重新審查要求。

• 提供建構版本並將重新旋轉要求標示為已修正後，您不應重新開啟重新旋轉要求來新增其他 CL。如有其他需要合併的修補程式，請務必提交新的重新旋轉要求。

• 針對每個考慮的 CL，新增下列標記。

  • Bug：每個 CL 的提交訊息都必須加入錯誤 ID。
  • Change-Id：必須與基本分支版本變更的 Change-Id 相同。

• 如果重新旋轉要求需要您回覆，但您未在三個工作天內回覆，優先順序就會降低一個等級 (例如 P0 降級為 P1)。如果兩週內未回覆，系統會將錯誤標示為「不會修正 (已過時)」。

提交重新旋轉要求

下圖顯示重新旋轉程序。OEM 合作夥伴 (您) 提出重新旋轉要求後，就會啟動這項程序。

圖 2. 重新旋轉程序

如要進入重製程序，請按照下列步驟操作：

1. 填寫 GKI Respin 申請表單， 並立即與 Google 客戶技術顧問聯絡。這份表單會建立 GKI 重製要求錯誤。您 (要求者)、GKI 團隊和您新增至錯誤副本清單的特定使用者，都能看到重新旋轉要求錯誤。
   • 如果您已修正問題，要求應指向 AOSP 中的修補程式提交內容，以便 Google 審查。如果無法提交修補程式，請將修補程式以文字檔形式附加至要求。
   • 如果沒有修正程式，要求中必須盡可能包含詳細資訊，包括核心版本號碼和記錄，以便 Google 協助偵錯問題。
2. Google GKI 團隊會審查要求，並核准要求，或是在需要更多資訊時將要求指派回給您。
3. 雙方同意修正方式後，Google GKI 團隊會進行程式碼審查 (CR+2)。審查會在 ESRT 時間範圍內開始。GKI 團隊會合併、建構、測試迴歸，並認證變更。
4. 二進位檔會發布至 ci.android.com。ESRT 時間範圍結束後，Google GKI 團隊會將要求標示為已修正，並參照重新旋轉的建構版本。系統也會在「通用核心映像檔 (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、裝置或型號專屬，GKI 團隊可以確保變更新增的程式碼只會在受影響的裝置、型號或 SKU 上執行。

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

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

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