本頁面說明 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 月 17 日 | 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。只要原始設備製造商 (OEM) 通過 GKI 認證的版本，就能根據 Android 安全性公告 (ASB) 的 LTS 規定發布。
每週開發人員版本
版本會透過 Cuttlefish 進行測試，確保符合最低品質標準。當變更合併後，您可以透過 Android CI 自助服務取得 GKI 二進位檔。每週的版本不會獲得認證，但可用於開發和測試的基準。每週版本無法用於為使用者製作的正式版裝置。
每月認證版本
GKI 每月版本包含經過測試的 boot.img，其中含有 Google 插入的憑證，可證明二進位檔是根據已知來源程式碼基準建構而成。
每個月都會在入住截止日 (通常是該月的第二個每週版本) 之後，獲選為每月 GKI 的每月版本 (未經過認證)。選取每月候選版本後，系統就不會將新變更納入該月的版本。在關閉期間，您只能修正導致測試失敗的錯誤。候選版通過品質保證 (如 GKI 資格一節中所述)，確保符合 GSI+GKI 版本與參考裝置和切割魚的做法通過。
圖 1. GKI 發布時間表
緊急重設計過程
「重新認證」是指在 GKI 核心公開發布後，重新合併、重新建構、重新測試和重新認證二進位檔的程序。您可以在下列任何情況下，要求重新發布已認證的二進位檔：
- 如要更新符號清單。
- 修正錯誤，包括在無線電服務供應商實驗室核准期間發現的錯誤。
- 如要新增供應商掛鉤。
- 將修補程式套用至現有功能。
- 套用安全性修補程式 (6 個月後)。
安全性修補程式會自動合併至發布分支，發布分支發布後最多 6 個月。6 個月的截止日期過後，您必須要求重新發布，才能在分支中套用安全性修補程式。
重播要求規範
提出重審申請前，請注意下列規範：
每月版本的初始公開版本發布後，您只能在發布分支中進行重釘。
我們只會接受特定發布分支的重新發布要求，且要求必須在最初公開發布後的六個月內提出。六個月後，我們才有資格重新綁定 Android 安全性公告中提及的安全性修補程式。
如果 Android 安全性公告 (ASB) 定義的 LTS 需求條件，導致分支版本不符合規定，分支版本就會遭到淘汰。恕不接受針對已淘汰的分支版本重新發出要求。特定 GKI 發布分支的淘汰日期會列在每月 GKI 發布版本的「發布版本」下方。為協助您日後的規劃，LTS 規定會在每年 5 月和 11 月更新。舉例來說，由於
android12-5.10-2023-07分支版本 (5.10.177) 不符合 ASB-2024-05 的 LTS 要求，因此不支援android12-5.10-2023-07分支版本 (5.10.177) 重釘。只有在需要緊急修正錯誤、更新符號清單，或是套用修補程式來修正現有功能時，才適用於重新固定。
所有要納入月度發布分支的修補程式都必須已合併至主要 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)。如果您未在兩週內回應，系統會將該錯誤標示為「Won't Fix (Obsolete)」。
提出重新綁定要求
下圖顯示重發程序。這項程序會在原始設備製造商 (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)、裝置或型號有關，則 GKI 團隊可以確保變更內容新增的程式碼只會在受影響的裝置、型號或 SKU 上執行。
統一重製的最大優點，就是使用相同版本基礎的每部裝置都能互相受惠，特別是如果他們發現的錯誤是通用且適用於所有使用者的話。在電信業者測試中發現的核心核心錯誤，就是這個概念的具體例子。
在某些情況下，Google 會提供 OEM 修補程式和問題情境的具體資訊，讓 OEM 評估在自家產品中導入修補程式的影響和風險嗎？
在瞭解問題並收集所有詳細資料之前，Google 絕不會在重發版本中加入變更。這會顯示在變更記錄 (修訂訊息) 中。Google 不會揭露影響到哪個特定裝置，但原始設備製造商 (OEM) 仍可在變更記錄中找到問題說明和解決方案。