通用内核映像 (GKI) 发布流程

本文档介绍了 GKI 的发布状况，包括每周、每月和带外紧急发布版本。本文档旨在向 OEM 提供关于从何处获取 GKI 以及带外紧急修复流程的指南。OEM 还可以参阅 GKI 开发指南，详细了解如何与 Android 内核团队合作，针对自家产品优化 GKI 内核。

GKI 发布频率

在 KMI 冻结后，GKI 每月发布一次。

Android 13、14 和 15 GKI 版本

下表仅适用于 android13-5.10、android13-5.15 和 android14-6.1。

GKI 每月认证的 build	签入截止日期	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 每月版本。 android15-6.6 将从 2024 年 7 月开始遵循相同的发布频率。

GKI 每月认证的 build	签入截止日期	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 每月认证的 build	签入截止日期	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 build 有效性

OEM 可以使用最新发布的 Android GKI。OEM 可以在推出设备时搭载经 GKI 认证的 build，只要这些 build 符合 Android 安全公告 (ASB) 中的 LTS 要求。

每周开发版本

系统会使用 cuttlefish 对版本进行测试，以确保它们符合最低质量标准。

变更合并后，您可以在 ci.android.com 中自助获取 GKI 二进制文件。每周 build 不会获得认证，但可以用作开发和测试的基准。每周 build 不能用于面向最终用户的正式版设备 build。

每月认证的版本

GKI 每月版本包含经过测试的 boot.img，其中包含 Google 插入的证书，用于证明二进制文件是基于已知的源代码基准构建的。

每个月，在签入截止日期后，一个 GKI 每月候选版本（未经认证）会被选中，并通常会成为该月第二个每周 build。选择了每月候选版本后，当月版本中不会纳入任何新变更。在关闭期间，我们可能只会着手修复会导致测试失败的 bug。候选版本会经过质量保证流程（如“GKI 资格审查”部分中所述），以确保 GSI+GKI build 会在参照设备和 Cuttlefish 上通过合规性测试。

GKI 发布频率时间表 图 1. GKI 发布时间表

紧急 respin 流程

respin 是指在 GKI 内核公开发布后重新合并、重新构建、重新测试和重新认证二进制文件的过程。针对以下任一情况，您可以请求对经过认证的二进制文件进行 respin：

更新符号列表。
对 bug 应用修复，包括在运营商实验室审批期间发现的 bug。
添加供应商钩子。
对现有功能应用补丁。
应用安全补丁（6 个月后）。

安全补丁会在分支发布后最多 6 个月内自动合并到版本分支。超过此 6 个月的期限后，您必须请求 respin 才能对分支应用安全补丁。

在请求 respin 之前，请注意以下准则：

只能在每月 build 首次公开发布后对发布分支进行 respin。
我们只在首次公开发布后最多六个月内接受针对给定发布分支的 respin 请求。六个月后，只有当针对 Android 安全公告中引用的安全补丁时，分支才符合进行 respin 的要求。
当由 Android 安全公告 (ASB) 定义的 LTS 要求导致分支不合规时，该分支会被废弃。针对已废弃分支的 respin 请求不被接受。给定 GKI 发布分支的废弃日期包含在发布版本下的每月 GKI 发布 build 备注中。为便于未来规划，每年 5 月和 11 月都会更新 LTS 要求。android12-5.10-2023-07 分支 (5.10.177) 不符合 ASB-2024-05 的 LTS 要求。
respin 仅适用于紧急 bug 修复、符号列表更新，或应用补丁来修复现有功能。
纳入每月发布分支的所有补丁必须已合并到主 GKI 开发分支中。例如，如果对 android12-5.10-2022-09 进行 respin 需用到某个补丁，该补丁必须已合并到 android12-5.10 中。
您必须从主 GKI 开发分支中挑选最合适的补丁，并将补丁上传到每月发布分支。
在 respin 请求中，您必须为请求分配优先级（紧急程度）。这个优先级有助于 GKI 团队及时更好地为合作伙伴提供帮助。对于关键请求或具有时效性的请求，将优先级标记为 P0。对于 P0 和 P1 请求，您还必须说明紧急程度。下表提供了 bug 优先级和解决时间 (ESRT) 的对应关系：

优先级 ESRT

P0 2 个工作日

P1 5 个工作日

P2 10 个工作日

P3 15 个工作日

优先级	ESRT
P0	2 个工作日
P1	5 个工作日
P2	10 个工作日
P3	15 个工作日

您必须为每个发布分支分别提交一个 respin 请求。例如，如果 android12-5.10-2022-08 和 android12-5.10-2022-09 都需要 respin，您必须创建两个 respin 请求。
当您获得 build 且 respin 请求标记为已修复后，您不应重新打开该 respin 请求来添加其他 CL。如果存在需要合并的其他补丁，您必须提交新的 respin 请求。
对于每个要处理的 CL，添加以下标记。没有这些信息，respin 请求的进度会被阻断。
- Bug：必须将 bug ID 添加到每个 CL 的提交消息中。
- Change-Id：必须与基本分支更改的变更 ID 相同。
如果 respin 请求需要您的响应，但您未在三个工作日内回复，则优先级会降级一个级别（例如，P0 会降级为 P0）。如果您在两周内未回复，该 bug 会被标记为 Won't Fix (Obsolete)。

提交 respin 请求

下图显示了 respin 流程。该流程从 OEM 合作伙伴（您）提交 respin 请求开始。

紧急 respin 流程 图 2. respin 流程

如需进入 respin 流程，请执行以下操作：

填写 GKI respin 请求表单，并立即与您的 Google 技术支持客户经理联系。此表单会创建一个 GKI respin 请求 bug。您（请求者）、GKI 团队以及您添加到 bug 的抄送列表中的特定人员可以看到 respin 请求 bug。
- 如果您已有修复程序，应将该请求指向 AOSP 中的补丁提交流程，以便 Google 进行审核。如果提交补丁不可行，请将针对该请求的补丁以文本文件的形式附加。
- 如果您还没有修复程序，则必须针对该请求提供尽可能多的信息（包括内核版本号和日志），以便 Google 可以帮助调试该问题。
Google GKI 团队会审核请求并进行审批；或者如果需要更多信息，则会将请求发还给您。
在就修复程序商定一致后，Google GKI 团队会审核 (CR+2) 这项变更的代码。审核会开始 ESRT 时段。GKI 团队会合并、构建和测试以便进行回归，并认证相应更改。
二进制文件将发布到 ci.android.com。ESRT 时段结束，Google GKI 团队会将请求标记为已修复并引用 respin build。respin build 也会在通用内核映像 (GKI) 发布 build 页面上发布。

GKI 资格审查

GKI build 的类型	质量保证措施	备注
每周	cuttlefish 测试启动一部分 VTS 一部分 CTS	未经认证。仅用于测试和启动设备。无法用于发布设备。
每月（经过认证）	cuttlefish 测试启动 VTS CTS 参照硬件测试启动 VTS CTS
respin（已认证）	cuttlefish 测试启动 VTS 一部分 CTS 参照设备测试启动 VTS	在经 GKI 认证的 build 的基础上构建。 build 经资格审查后通过了认证。

GKI build 的类型

质量保证措施

备注

每周

cuttlefish 测试

启动
一部分 VTS
一部分 CTS

未经认证。仅用于测试和启动
设备。
无法用于发布设备。

每月（经过认证）

cuttlefish 测试

启动
VTS
CTS

参照硬件测试

启动
VTS
CTS

respin（已认证）

cuttlefish 测试

启动
VTS
一部分 CTS

参照设备测试

启动
VTS

在经 GKI 认证的 build 的基础上构建。
build 经资格审查后通过了认证。

从哪里获取 build 工件

所有版本的工件都可以从 ci.android.com 获取。

您可以在 CI 上找到更多信息，包括 Android 持续集成信息中心内的测试结果。

常见问题解答

能否基于已发布的 GKI 构建新的 GKI 二进制文件？

能，这称为 respin。只要已发布的 GKI build（请求 respin 的目标对象）符合 Android 安全公告 (ASB) 中的 LTS 要求，就可以支持 respin 流程。

能否重现 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 二进制文件（包括紧急 spin 补丁）是否已基于最新的代码库构建？

否。respin 仅包含基于所选每月经认证的内核的补丁。这些 respin 包含针对妨碍发布的 bug 的所有修复程序；修复程序是由 OEM 在指定时间之前使用相应的基础每月版本报告的。请参阅以下示例，了解此类情况是如何发生的。

OEM1 和 OEM2 决定从 2021 年 11 月开始使用 GKI 二进制版本。
OEM1 和 OEM2 发现需要使用补丁来支持的问题。这些补丁可能各不相同，也可能相同。
基于 2021 年 11 月二进制文件的 respin 包含 OEM1 和 OEM2 在 respin 期间报告的一些修复程序，可修复会妨碍发布的 bug；除此以外，不含其他内容。
第二个列表项中提及的问题也会包含在后续的 GKI 每月版本中。

10 月 respin 中包含 OEM 提交的所有补丁，但其他 OEM 补丁不会影响我们，因为它们没有对我们的产品进行专门测试。能否只包含我们的补丁？

不可能。目前无法扩展“per-OEM”respin 路径。相反，GKI 团队会仔细研究纳入 respin build 的每项变更，并在创建新 build 之前使用所有可用硬件来测试变更。如果 GKI 团队发现这是某个 OEM/设备/型号特有的问题，可以确保该变更添加的代码仅在受影响的设备/型号/SKU 上执行。

统一 respin 的主要优势在于，使用相同版本基础的每个设备能够互相受益，特别是在其发现的 bug 具有常规性且所有用户都会遇到时。在运营商测试中发现的核心内核 bug 就是此概念的一个具体示例。

Google 是否提供了有关 OEM 补丁的具体信息和问题场景，以便 OEM 可以评估在其产品中实现补丁的影响和风险？

只有在了解问题并收集所有详细信息后，Google 才会向 respin build 中添加变更。这可在变更日志（提交消息）中看到。Google 不会披露受影响的具体设备，但 OEM 随时可以在变更日志中找到问题说明和解决方案。