请求 respin

respin 是指在 GKI 内核公开发布后重新合并、重新构建、重新测试和 重新认证二进制文件的过程。

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

资格条件和生命周期

  • 时间： 只有在季度 build 首次公开发布后，您才能对发布分支请求 respin。我们只在首次公开发布后最多六个月内接受针对给定发布分支的 vendor-hooks 或其他功能的 respin 请求。
  • 安全性和 LTS： 六个月后，只有当针对 Android 安全公告 (ASB) 中引用的安全补丁或关键 bug 修复时，分支才符合 respin 的要求。
  • 废弃： 当由 Android 安全公告 (ASB) 定义的 LTS 要求导致分支不合规时，该分支会被废弃。针对已废弃分支的 respin 请求不被接受。
    • 给定 GKI 发布分支的废弃日期包含在发布版本下的季度 GKI 发布 build 备注中。 例如，2025 年 9 月发布的版本 支持 respin，直到 2027 年 3 月。此日期反映了自 2025 年 9 月起发布的版本的 LTS 2.0 内核版本生命周期为 18 个月（2025 年 9 月之前的版本生命周期为 12 个月）。
  • 范围： respin 仅适用于紧急 bug 修复、符号列表更新，或应用补丁来修复现有功能。
  • 16 KB GKI 版本： 对于受支持的 16 KB GKI 分支（android15-6.6、 android16-6.12 和 android17-6.18），按需 respin 遵循与 4 KB build 相同的 respin 请求表单、 补丁提交标准和资格流程。 您无需同时更新 4 KB 和 16 KB 内核，但 我们建议您这样做。

补丁提交标准

为了满足 respin 请求 处理的预期标准解决时间 (ESRT)，提交到发布分支的所有补丁都必须遵守以下技术规则。

可信来源和择优挑选

  • 先开发分支： 纳入季度发布分支的所有补丁必须已合并到主 GKI 开发分支中。例如，如果对 android15-6.6-2025-08 进行 respin 需用到某个补丁，该补丁必须已合并到 android15-6.6 中。
  • 干净的择优挑选： 您必须直接从开发分支中择优挑选补丁。请勿从其他发布分支中择优挑选（例如，不要从 2025-08 挑选到 2025-09），因为这可能会导致作者或提交信息与开发分支中的版本不一致。我们不会接受信息不一致的补丁。
  • 保留元数据： 保留原始提交元数据（例如，作者、原始时间戳）。使用 git cherry-pick -x 保留元数据。

提交链

  • 顺序链： 如果 respin 请求涉及多个补丁，请将它们作为单个顺序链 的提交上传。
  • ABI 和 KMI 位置： 如果多补丁 respin 包含内核模块接口 (KMI) 和应用二进制接口 (ABI) 更新（例如，符号列表更改或 XML/STG 文件更新），请将这些提交放在提交链的末尾。
  • 变基： 如果您在链中修改父级提交，则必须将所有子级补丁变基到其父级补丁的最新修订版本之上，以避免 build 失败。
  • 冲突解决： 验证任何补丁中都没有冲突标记。
  • build 验证： 整个提交链必须成功构建。

必需的标记

如果没有提交消息中的以下标记，respin 请求的进度会被阻断：

  • Change-Id：必须与开发分支更改的 Change-Id 相同。
    • 例外情况：如果补丁作为 LTS 更新的一部分合并到开发分支中，则应择优挑选 LTS 版本，并将其格式设置为 UPSTREAM 补丁。请参阅 如何向 Android 通用内核提交补丁。
  • Bug（现有）：不得移除原始开发 分支提交中的现有 Bug: XYZ 标记。
  • Bug（respin）：您必须添加新的 Bug: XYZ 标记，其中 XYZ 对应于与当前 respin 请求关联的 bug ID。
  • 根据需要更新 UPSTREAM 提交标记：从开发分支向发布分支择优挑选 CL 时，如果 CL 标记为 UPSTREAM，请考虑以下情形：
    • 如果 CL 干净地应用于发布分支，则无需执行任何其他操作。
    • 如果 CL 未干净地应用，请修复冲突， 将标记更新为 BACKPORT，并记录作为 冲突解决的一部分所做的工作，请参阅 从 mainline Linux 进行反向移植的要求。

优先级和 ESRT

为 respin 请求分配优先级（紧急程度），以帮助 GKI 团队确定优先顺序。这个优先级有助于 GKI 团队及时更好地为 合作伙伴提供帮助。

  • 对于关键请求或具有时效性的请求，将优先级标记为 P0 。
  • 对于 P0 和 P1 请求，您还必须说明紧急程度。

下表提供了 bug 优先级和解决时间 (ESRT) 的对应关系：

优先级ESRT
P02 个工作日
P15 个工作日
P210 个工作日
P315 个工作日

SLA 政策

  • 为每个发布分支分别提交一个 respin 请求。
  • 如果您对标记为已修复的 respin 请求进行了更改，请提交新的 respin 请求。请勿重新打开请求以添加其他变更列表 (CL)。
  • 如果 respin 请求需要您的响应，但您未在三个工作日内回复，则优先级会降级一个级别，例如，P0 会降级为 P1 。
  • 如果您在两周内未回复，该 bug 会被标记为不会修复 （已过时）。

提交 respin 请求

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

紧急 respin 流程 图 1.紧急 respin 流程。

如需提交 respin 请求，请执行以下操作：

  1. 填写 GKI respin 请求表单，并立即与 您的 Google 联系人联系。

    • 此表单会创建一个 GKI respin 请求 bug。

  2. 准备补丁：

    • 验证补丁是否已合并到 GKI 开发分支中。
    • 将补丁应用于相应的 GKI 发布分支。
    • 修改择优挑选的补丁，使其包含引用 respin 请求 ID 的 Bug: XYZ 标记。

    示例： 如需从 android16-6.12 向 android16-6.12-2025-12 择优挑选 CL，请执行以下操作：

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. 提交 bug。提交请求后，会发生以下情况：

    • 提交后的审核流程：

      • Google GKI 团队会审核请求并进行审批；或者如果需要更多信息，则会将请求发还给您。
      • 在就修复程序商定一致后，Google GKI 团队会审核这项变更的代码。ESRT 计时器在此审核期间处于活动状态。不过，如果补丁被拒绝或需要返工，ESRT 计时器会重置。
      • GKI 团队会合并、构建和测试以便进行回归，并认证相应更改。

    • 发布：