本頁說明 GKI 的發布方式，包括每週、每月和非正式緊急發布。本文件的目標是為原始設備製造商 (OEM) 提供指引，說明如何取得 GKI，以及如何處理非預期情況下的緊急修正。原始設備製造商 (OEM) 也可以使用 GKI 開發，進一步瞭解如何與 Android 核心團隊合作，為自家產品最佳化 GKI 核心。
GKI 發布頻率
在 KMI 凍結後，GKI 會以每月一輪的頻率發布。
Android 13、14 和 15 GKI 版本
下表僅適用於 android13-5.10、android13-5.15 和 android14-5.15。
| GKI 每月認證版本 | 入住截止日期 | GKI 預先載入就緒日期 | 確認嗎？ |
|---|---|---|---|
| 11 月 | 2024 年 11 月 11 日 | 2024 年 11 月 27 日 | 是 |
| 1 月 | 2025 年 1 月 14 日 | 2025 年 1 月 31 日 | 是 |
| 3 月 | 2025 年 3 月 14 日 | 2025 年 3 月 31 日 | 是 |
下表僅適用於 android14-6.1 和 android15-6.6。
| GKI 每月認證版本 | 入住截止日期 | GKI 預先載入就緒日期 | 確認嗎？ |
|---|---|---|---|
| 10 月 | 2024 年 10 月 1 日 | 2024 年 10 月 14 日 | 是 |
| 11 月 | 2024 年 11 月 1 日 | 2024 年 11 月 15 日 | 是 |
| 12 月 | 2024 年 12 月 2 日 | 2024 年 12 月 16 日 | 是 |
| 1 月 | 2025 年 1 月 6 日 | 2025 年 1 月 22 日 | 是 |
Android 12 GKI 版本
2024 年 5 月之後，android12-5.10 GKI 會以季度為週期，並在每月中旬發布。下表僅適用於 android12-5.10。
| GKI 每月認證版本 | 入住截止日期 | GKI 預先載入就緒日期 | 確認嗎？ |
|---|---|---|---|
| 11 月 | 2024 年 11 月 1 日 | 2024 年 11 月 15 日 | 是 |
| 2 月 | 2025 年 2 月 3 日 | 2025 年 2 月 17 日 | 是 |
原始設備製造商的 GKI 版本有效性
原始設備製造商 (OEM) 可以使用最近發布的 Android GKI。只要符合 Android 安全性通報 (ASB) 中的 LTS 規定，原始設備製造商 (OEM) 就可以推出經過 GKI 認證的版本。
每週開發人員版本
版本會透過 Cuttlefish 進行測試，確保符合最低品質標準。當變更合併後，您可以透過 Android CI 自助服務取得 GKI 二進位檔。每週的版本不會獲得認證，但可用於開發和測試的基準。每週版本無法用於為使用者製作的正式版裝置。
每月認證版本
GKI 每月版本包含經過測試的 boot.img，其中含有 Google 插入的憑證，可證明二進位檔是根據已知來源程式碼基準建構而成。
每個月，系統會在檢查結束日期 (通常是當月第二個週的版本) 後，選取 GKI 每月候選版本 (未認證)。選取每月候選版本後，系統就不會將新變更納入該月的版本。在關閉窗口期間，只能針對導致測試失敗的錯誤修正問題。候選版本會經過品質管控，如GKI 資格條件一節所述，以確保 GSI+GKI 版本在參考裝置和 cuttlefish 上通過法規遵循測試。
圖 1. GKI 發布時間表
緊急重設計過程
重轉換是指在發布 GKI 核心的公開版本後，重新匯出、重建、重新測試及重新認證二進位檔的程序。您可以在下列任何情況下，要求重新發布已認證的二進位檔：
- 如要更新符號清單。
- 修正錯誤，包括在無線電服務供應商實驗室核准期間發現的錯誤。
- 如要新增供應商掛鉤。
- 將修補程式套用至現有功能。
- 套用安全性修補程式 (6 個月後)。
安全性修補程式會自動合併至發布分支，發布分支發布後最多 6 個月。6 個月的截止日期過後，您必須要求重新發布，才能在分支中套用安全性修補程式。
重轉要求指南
提出重審申請前，請注意下列規範：
每月版本的初始公開版本發布後，您只能在發布分支中進行重釘。
我們只會接受特定發布分支的重新發布要求，且要求必須在最初公開發布後的六個月內提出。六個月後，分支版本只能針對 Android 安全性公告中提及的安全性修補程式進行重發。
如果 LTS 規定 (由 Android 安全性公告 (ASB) 定義) 導致分支版本不符合規定，則該分支版本會淘汰。我們不會接受已淘汰分支的重新發布要求。特定 GKI 發布分支的淘汰日期會列在每月 GKI 發布版本的「發布版本」下方。為協助您日後的規劃，LTS 規定會在每年 5 月和 11 月更新。舉例來說，
android12-5.10-2023-07分支 (5.10.177) 在 2024 年 5 月 1 日後不支援重發，因為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：必須將錯誤 ID 新增至每個 CL 的提交訊息。Change-Id：必須與基礎分支版本變更的 Change-Id 相同。
如果重審要求需要您回覆，但您未在三個工作天內回覆，則優先順序會降一級 (例如，P0 會降級為 P1)。如果您在兩週內未回應，該錯誤就會標示為「不會修正 (已淘汰)」。
提交重發要求
下圖顯示重發程序。當 OEM 合作夥伴 (您) 提交重審要求時，這個程序就會開始。
圖 2. 重送程序
如要進入重試程序，請按照下列步驟操作：
- 填寫 GKI 重播申請表單，並立即與 Google 技術客戶經理聯絡。這份表單會建立 GKI 重送要求錯誤。您 (提出要求者)、GKI 團隊，以及您在錯誤的副本清單中新增的特定使用者，都可以查看要求重播的錯誤。
- 如果您已修正問題，請在要求中指向 AOSP 中的修補程式提交內容，以便 Google 進行審查。如果無法提交修補程式，則必須將修補程式附加為文字檔，並附加至要求中。
- 如果您沒有修正程式，請務必在要求中提供盡可能多的資訊，包括核心版本號碼和記錄，以便 Google 協助您偵錯。
- Google GKI 團隊會審查要求並核准，或在需要更多資訊時將要求指派回給您。
- 在同意修正問題後，Google GKI 團隊會對變更進行程式碼審查 (CR+2)。審查作業會在 ESRT 時間範圍內開始。GKI 團隊會合併、建構、測試迴歸，並認證變更。
- 二進位檔會發布至 ci.android.com。ESRT 時間範圍結束後，Google GKI 團隊會將要求標示為已修正，並參照重新發布的版本。這項版本也會發布至「Generic Kernel Image (GKI) release builds page」頁面。
GKI 資格
| GKI 建構類型 | 品質強制執行 | 注意事項 |
|---|---|---|
| 每週 | Cuttlefish 測試
|
|
| 每月 (已認證) | Cuttlefish 測試
|
|
| 重播 (已認證) | Cuttlefish 測試
|
|
取得建構成果的位置
您可以前往 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/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh
您可以從 out/.../dist 擷取 GKI 構件副本。
是否已使用最新的程式碼集建構 GKI 二進位檔 (包括緊急旋轉修補程式)？
否。Respins 只包含已選取的每月認證核心的修補程式。這些重發版本包含所有啟動阻斷錯誤修正，這些修正是在使用相應每月基本版本的期間，由原始設備製造商回報。請參考以下範例，瞭解這類情況的發生方式。
- OEM1 和 OEM2 決定使用 2021 年 11 月發布的 GKI 二進位檔。
- OEM1 和 OEM2 發現需要支援修補程式的問題。這些修補程式可能不同，也可能相同。
- 在 2021 年 11 月二進位檔上方的重發版本，在重發期間由 OEM1 和 OEM2 回報啟動封鎖修正，但沒有其他內容。
- 第二個項目中提到的問題也包含在後續的 GKI 每月版本中。
10 月的修補版本包含所有 OEM 提交的修補程式，但其他 OEM 修補程式會影響我們，因為這些修補程式並未經過我們的產品專門測試。是否可以只加入我們的修補程式？
這是不可能的。「每個原始設備製造商 (OEM)」的重新提交路徑無法擴充。相反地，GKI 團隊會仔細檢查進入重發版本的每項變更，並在建立新版本前，使用所有可用的硬體測試變更。如果 GKI 團隊發現問題是特定 OEM、裝置或型號的問題，他們可以確保變更所新增的程式碼只會在受影響的裝置、型號或 SKU 上執行。
統一重製的最大優點，就是使用相同版本基礎的每部裝置都能從中受益，特別是如果他們發現的錯誤是通用且適用於所有使用者的話。在電信業者測試中發現的核心核心錯誤，就是這個概念的具體例子。
在某些情況下，Google 會提供 OEM 修補程式和問題情境的具體資訊，讓 OEM 評估在自家產品中導入修補程式的影響和風險嗎？
在瞭解問題並收集所有詳細資料之前，Google 絕不會在重發版本中加入變更。這會顯示在變更記錄 (提交訊息) 中。Google 不會透露問題會影響哪些特定裝置，但原始設備製造商 (OEM) 隨時可以在變更記錄中找到問題說明和解決方案。