本文說明 GKI 的發布方式,包括每週、每月及脫離頻帶的緊急版本。本文件旨在提供原始設備製造商 (OEM) 瞭解如何選擇 GKI,以及跳脫頻帶緊急修正的程序。原始設備製造商也可參閱 GKI 開發指南,進一步瞭解如何與 Android Kernel 團隊合作,為產品最佳化 GKI 核心。
GKI 發布頻率
GKI 會在 KMI 凍結後每月發布。
Android 13、14 和 15 GKI 版本
下表僅適用於 android13-5.10
、android13-5.15
和 android14-6.1
。
GKI 每月認證版本 | 入住截止日期 | GKI 預先載入準備日期 | 已確認嗎? |
---|---|---|---|
10 月 | 2022 年 10 月 14 日 | 2022 年 10 月 31 日 | 可 |
11 月 | 2022 年 11 月 14 日 | 2022 年 11 月 30 日 | 可 |
12 月 | 2022 年 12 月 9 日 | 2022 年 12 月 21 日 | 可 |
1 月 | 2023 年 1 月 17 日 | 2023 年 1 月 31 日 | 可 |
2 月 | 2023 年 2 月 15 日 | 2023 年 2 月 28 日 | 可 |
3 月 | 2023 年 3 月 15 日 | 2023 年 3 月 31 日 | 可 |
4 月 | 2023 年 4 月 13 日 | 2023 年 4 月 28 日 | 可 |
5 月 | 2023 年 5 月 17 日 | 2023 年 5 月 31 日 | 可 |
6 月 | 2023 年 6 月 15 日 | 2023 年 6 月 30 日 | 可 |
7 月 | 2023 年 7 月 18 日 | 2023 年 7 月 31 日 | 可 |
8 月 | 2023 年 8 月 16 日 | 2023 年 8 月 31 日 | 可 |
9 月 | 2023 年 9 月 14 日 | 2023 年 9 月 29 日 | 可 |
10 月 | 2023 年 10 月 18 日 | 2023 年 10 月 31 日 | 可 |
11 月 | 2023 年 11 月 10 日 | 2023 年 11 月 30 日 | 可 |
12 月 | 2023 年 12 月 7 日 | 2023 年 12 月 22 日 | 可 |
1 月 | 2024 年 1 月 16 日 | 2024 年 1 月 31 日 | 可 |
2 月 | 2024 年 2 月 13 日 | 2024 年 2 月 29 日 | 可 |
3 月 | 2024 年 3 月 13 日 | 2024 年 3 月 29 日 | 可 |
4 月 | 2024 年 4 月 16 日 | 2024 年 4 月 30 日 | 可 |
5 月 | 2024 年 5 月 14 日 | 2024 年 5 月 31 日 | 可 |
6 月 | 2024 年 6 月 12 日 | 2024 年 6 月 28 日 | 可 |
7 月 | 2024 年 7 月 16 日 | 2024 年 7 月 31 日 | 可 |
8 月 | 2024 年 8 月 15 日 | 2024 年 8 月 30 日 | 可 |
9 月 | 2024 年 9 月 17 日 | 2024 年 9 月 30 日 | 可 |
10 月 | 2024 年 10 月 15 日 | 2024 年 10 月 31 日 | 可 |
11 月 | 2024 年 11 月 11 日 | 2024 年 11 月 27 日 | 可 |
12 月 | 2024 年 12 月 6 日 | 2024 年 12 月 23 日 | 可 |
2024 年 1 月起,我們會按照下表指示的每月頻率,恢復每月 android14-5.15
版本。自 2024 年 7 月起,android15-6.6
也會遵循相同的發布頻率。
GKI 每月認證版本 | 入住截止日期 | GKI 預先載入準備日期 | 已確認嗎? |
---|---|---|---|
1 月 | 2024 年 1 月 16 日 | 2024 年 1 月 31 日 | 可 |
2 月 | 2024 年 2 月 13 日 | 2024 年 2 月 29 日 | 可 |
3 月 | 2024 年 3 月 4 日 | 2024 年 3 月 15 日 | 可 |
4 月 | 2024 年 4 月 1 日 | 2024 年 4 月 17 日 | 可 |
5 月 | 2024 年 5 月 1 日 | 2024 年 5 月 17 日 | 可 |
6 月 | 2024 年 6 月 3 日 | 2024 年 6 月 17 日 | 可 |
7 月 | 2024 年 7 月 1 日 | 2024 年 7 月 15 日 | 可 |
8 月 | 2024 年 8 月 1 日 | 2024 年 8 月 16 日 | 可 |
9 月 | 2024 年 9 月 2 日 | 2024 年 9 月 16 日 | 可 |
10 月 | 2024 年 10 月 1 日 | 2024 年 10 月 14 日 | 可 |
11 月 | 2024 年 11 月 1 日 | 2024 年 11 月 15 日 | 可 |
12 月 | 2024 年 12 月 2 日 | 2024 年 12 月 16 日 | 可 |
Android 12 GKI 版本
2024 年 5 月後,android12-5.10
GKI 會按季發布,並在月中發布。
下表列出僅適用於 android12-5.10
。
GKI 每月認證版本 | 入住截止日期 | GKI 預先載入準備日期 | 已確認嗎? |
---|---|---|---|
7 月 | 2023 年 7 月 3 日 | 2023 年 7 月 14 日 | 可 |
9 月 | 2023 年 9 月 1 日 | 2023 年 9 月 15 日 | 可 |
11 月 | 2023 年 11 月 3 日 | 2023 年 11 月 17 日 | 可 |
1 月 | 2024 年 1 月 5 日 | 2024 年 1 月 19 日 | 可 |
3 月 | 2024 年 3 月 4 日 | 2024 年 3 月 15 日 | 可 |
5 月 | 2024 年 5 月 1 日 | 2024 年 5 月 17 日 | 可 |
8 月 | 2024 年 8 月 1 日 | 2024 年 8 月 16 日 | 可 |
11 月 | 2024 年 11 月 1 日 | 2024 年 11 月 15 日 | 可 |
2 月 | 2025 年 2 月 3 日 | 2025 年 2 月 17 日 | 可 |
原始設備製造商 (OEM) 的 GKI 建構有效性
原始設備製造商 (OEM) 可以使用最近發布的 Android GKI。只要原始設備製造商 (OEM) 通過 GKI 認證的版本,就能根據 Android 安全性公告 (ASB) 的 LTS 規定發布。
每週開發版本
發布內容已通過 cuttlefish 的測試,確保通過最低品質標準。當變更合併時,GKI 二進位檔適用於 ci.android.com 的自助式服務。每週版本不會經過認證,但可做為開發和測試的基準。每週版本無法讓使用者用於正式環境裝置版本。
每月認證版本
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):
優先順序 西班牙文 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 Respin 申請表,並立即與 Google 客戶技術顧問聯絡。這份表單會建立 GKI 重新釘選要求錯誤。您可以查看重新固定要求錯誤 (要求者)、GKI 團隊,以及您在錯誤 CC 清單加入的特定個人。
- 如果您已修正了問題,要求應指向 Android 開放原始碼計畫中的修補程式提交項目,以便 Google 進行審查。如果無法提交修補程式,則必須以文字檔案的形式將修補程式附加到要求中。
- 如果您沒有修正,要求中必須盡可能包含最多的資訊,包括核心版本號碼和記錄,以便 Google 協助對問題進行偵錯。
- Google GKI 團隊會審查並核准要求,如果需要更多資訊,則會指派給你。
- 雙方同意修正後,Google GKI 團隊的程式碼審查 (CR+2) 就會變更。審查程序始於 ESRT 時間範圍。GKI 團隊會合併、建構及執行迴歸測試,並認證變更
- 二進位檔會發布至 ci.android.com。ESRT 時間範圍結束後,Google GKI 團隊會將要求標示為已修正,並參照重新連線版本。重新綁定版本也會張貼在一般核心映像檔 (GKI) 發布子版本頁面中。
GKI 資格
GKI 建構類型 | 品質違規處置 | 備忘錄 |
---|---|---|
每週 | Cuttlefish 測試
|
|
每月 (已認證) | Cuttlefish 測試
|
|
Respins (認證) | Cuttlefish 測試
|
|
取得建構構件的位置
您可以到 ci.android.com 取得所有版本的成果。
您可以在 Android 持續整合資訊主頁中進一步瞭解 CI,包括測試結果。
常見問題
是否可以根據已發布的 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 團隊會仔細審查進入重新建構版本的每個變更,並在建立新建構作業之前,使用所有可用硬體測試變更。如果 GKI 團隊發現問題與特定原始設備製造商 (OEM)/裝置/型號有關,GKI 團隊可以確保變更內容新增的程式碼只會在受影響的裝置/型號/SKU 執行。
整合重新綁定的主要優點是,每部裝置只要使用相同的版本基礎,就能享有最佳優勢,特別是在發現通用且適用於所有使用者的錯誤時,更是如此。而在電信業者測試中發現的核心錯誤就是這個概念的具體範例。
Google 是否提供有關原始設備製造商 (OEM) 修補程式的具體資訊和問題情境資訊,以便原始設備製造商 (OEM) 評估為產品導入修補程式的影響和風險?
在沒有瞭解問題且已收集所有詳細資料前,Google 絕不會對重新釘選版本新增變更。這會顯示在變更記錄 (修訂訊息) 中。Google 不會揭露影響到哪個特定裝置,但原始設備製造商 (OEM) 仍可在變更記錄中找到問題說明和解決方案。