本頁說明 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 日 | 是 |
原始設備製造商 (OEM) 的 GKI 建構有效性
原始設備製造商 (OEM) 可以使用最近發布的 Android GKI。只要符合 Android 安全性通報 (ASB) 中的 LTS 規定，原始設備製造商 (OEM) 就可以推出經過 GKI 認證的版本。
每週開發人員版本
版本會透過 Cuttlefish 進行測試，確保符合最低品質標準。當合併變更時，GKI 二進位檔適用於 Android CI 中的自助式服務。每週版本不會經過認證，但可做為開發和測試的基準。每週版本無法讓使用者用於正式環境裝置版本。
每月認證版本
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：必須在每個 CL 的修訂訊息中加入錯誤 ID。Change-Id：必須與基礎分支版本變更的 Change-Id 相同。
如果重審要求需要您回覆，而您未在三個工作天內回覆，則優先順序會降一級 (例如，P0 降級為 P1)。如果您在兩週內未回應，該錯誤就會標示為「不會修正 (已淘汰)」。
提交重發要求
下圖顯示重發程序。當 OEM 合作夥伴 (您) 提交重審要求時，這個程序就會開始。
圖 2. 重送程序
如要進入重試程序，請按照下列步驟操作：
- 填寫 GKI 重播申請表單，並立即與 Google 技術客戶經理聯絡。這份表單會建立 GKI 重送要求錯誤。您 (提出要求者)、GKI 團隊，以及您在錯誤的副本清單中新增的特定使用者，都可以查看要求重播的錯誤。
- 如果您已修正了問題，要求應指向 Android 開放原始碼計畫中的修補程式提交項目，以便 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 二進位檔 (包括緊急旋轉修補程式)？
否。Respin 只會包含位於已選擇每月認證核心之上的修補程式。這些重發版本包含所有啟動阻斷錯誤修正，這些修正是在使用相應每月基本版本的期間，由原始設備製造商回報。請參考以下範例，瞭解這類情況的發生方式。
- 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) 隨時可以在變更記錄中找到問題說明和解決方案。