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

本文說明 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 版本搭配參考裝置和剪紙的測試通過。

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：重新固定流程

如何進入重新固定程序：

  1. 請填寫 GKI Respin 申請表，並立即與 Google 客戶技術顧問聯絡。這份表單會建立 GKI 重新釘選要求錯誤。您可以查看重新固定要求錯誤 (要求者)、GKI 團隊，以及您在錯誤 CC 清單加入的特定個人。
    • 如果您已修正了問題，要求應指向 Android 開放原始碼計畫中的修補程式提交項目，以便 Google 進行審查。如果無法提交修補程式，則必須以文字檔案的形式將修補程式附加到要求中。
    • 如果您沒有修正，要求中必須盡可能包含最多的資訊，包括核心版本號碼和記錄，以便 Google 協助對問題進行偵錯。
  2. Google GKI 團隊會審查並核准要求，如果需要更多資訊，則會指派給你。
  3. 雙方同意修正後，Google GKI 團隊的程式碼審查 (CR+2) 就會變更。審查程序始於 ESRT 時間範圍。GKI 團隊會合併、建構及執行迴歸測試，並認證變更
  4. 二進位檔會發布至 ci.android.com。ESRT 時間範圍結束後，Google GKI 團隊會將要求標示為已修正，並參照重新連線版本。重新綁定版本也會張貼在一般核心映像檔 (GKI) 發布子版本頁面中。

GKI 資格

GKI 建構類型 品質違規處置 備忘錄
每週 Cuttlefish 測試
  • 啟動程序
  • VTS 的子集
  • CTS 子集
  • 尚未取得認證。僅適用於測試且
    部裝置啟動。
  • 無法用於啟動裝置。
每月 (已認證) Cuttlefish 測試
  • 啟動程序
  • 影片觀看體驗 (VTS)
  • CTS
參照硬體測試
  • 啟動程序
  • 影片觀看體驗 (VTS)
  • CTS
Respins (認證) Cuttlefish 測試
  • 啟動程序
  • 影片觀看體驗 (VTS)
  • CTS 子集
參照裝置測試
  • 啟動程序
  • 影片觀看體驗 (VTS)
  • 以通過 GKI 認證的版本為基礎。
  • 建構通過資格通過認證。

取得建構構件的位置

您可以到 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) 仍可在變更記錄中找到問題說明和解決方案。