请求 respin

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

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

资格要求和生命周期

  • 时间：您只能在季度 build 首次公开发布后对发布分支进行 respin。仅在首次公开发布后最多六个月内接受针对给定发布分支的供应商钩子或其他功能的 respin 请求。
  • 安全性和 LTS：六个月后，只有当针对 Android 安全公告 (ASB) 中引用的安全补丁或严重 bug 修复时，分支才符合进行 respin 的要求。
  • 废弃：当由 Android 安全公告 (ASB) 定义的 LTS 要求导致分支不合规时，该分支会被废弃。针对已废弃分支的 respin 请求不被接受。
    • 给定 GKI 发布分支的废弃日期包含在“发布版本”下的季度 GKI 发布 build 备注中。例如，2025 年 9 月版本支持 respin，有效期至 2027 年 3 月。此日期反映了自 2025 年 9 月起发布的版本（2025 年 9 月之前的版本的使用期限为 12 个月）的 LTS 2.0 内核版本生命周期为 18 个月。
  • 范围：仅在需要紧急修复 bug、更新符号列表或应用补丁来修复现有功能时，才请求 respin。

补丁提交标准

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

可信来源和精选

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

提交链

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

必需的标记

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

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

优先级和 ESRT

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

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

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

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

SLA 政策

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

提交 respin 请求

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

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

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

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

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

  2. 准备补丁：

    • 验证补丁是否已合并到 GKI 开发分支。
    • 将补丁应用于相应的 GKI 发布分支。
    • 修改精选的补丁，以添加引用 respin 请求 ID 的 Bug: XYZ 标记。

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

    # 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 团队会合并、构建和测试以便进行回归，并认证相应更改。

    • 版本：