リスピンをリクエストする

リスピンとは、GKI カーネルの公開リリース後のバイナリの再統合、再ビルド、再テスト、および 再認定のプロセスを指します。

リスピンをリクエストする前に、次のガイドラインにご注意ください。

対象とライフサイクル

  • タイミング: リスピンは、四半期ビルドの最初の公開リリース後のリリース ブランチでのみリクエストできます。ベンダーフックやその他の機能のリスピン リクエストは、最初の公開リリースから最大 6 か月間、特定のリリース ブランチに対してのみリクエストしてください。
  • セキュリティと LTS: 6 か月間の経過後は、ブランチは Android のセキュリティに関する公開情報（ASB）に記載されているセキュリティ パッチまたは重大なバグの修正についてのみ、リスピンの対象となります。
  • 非推奨: Android のセキュリティに関する公開情報（ASB）で定義される LTS 要件が原因でブランチが準拠しなくなると、そのブランチは非推奨になります。非推奨のブランチに対するリスピン リクエストは受け入れられません。
    • 特定の GKI リリース ブランチが非推奨になる日は、リリースの四半期 GKI リリースビルド ノートに記載されます。 たとえば、2025 年 9 月のリリース は、2027 年 3 月までリスピンがサポートされます。この日付は、2025 年 9 月以降のリリースにおける LTS 2.0 カーネル バージョンの 18 か月のライフサイクルを反映しています（2025 年 9 月より前のリリースは 12 か月のライフサイクルでした）。
  • スコープ: リスピンは、緊急のバグの修正、シンボルリストの更新、既存機能の修正のためにパッチを適用する場合にのみリクエストしてください。
  • 16 KB GKI リリース: サポートされている 16 KB GKI ブランチ（android15-6.6、 android16-6.12、android17-6.18）のオンデマンド リスピンは、4 KB ビルドと同じリスピン リクエスト フォーム、 パッチ送信標準、認定プロセスに従います。 4 KB カーネルと 16 KB カーネルを同時に更新する必要はありませんが、 同時に更新することをおすすめします。

パッチ送信標準

リスピン リクエスト 処理の予想標準解決時間（ESRT）を満たすには、リリース ブランチに送信されるすべてのパッチが次の技術ルールに準拠している必要があります。

信頼できる情報源とチェリーピック

  • 最初に開発ブランチ: 四半期リリース ブランチに入るすべてのパッチは、すでにメインの GKI 開発ブランチに統合されている必要があります。たとえば、 リスピンにパッチが必要な場合、android15-6.6-2025-08 すでに android15-6.6 に統合されている必要があります。
  • クリーンなチェリーピック: パッチは開発ブランチから直接チェリーピックする必要があります。他のリリース ブランチからチェリーピックしないでください（たとえば、2025-08 から 2025-09 にチェリーピックしないでください）。開発ブランチのバージョンと一致しない作成者情報やコミット情報が生成される可能性があります。情報が一致しないパッチは受け付けられません。
  • メタデータの保持: 元のコミット メタデータ（作成者、元のタイムスタンプなど）を保持します。git cherry-pick -x を使用してメタデータを保持します。

コミット チェーン

  • 順次チェーン: リスピン リクエストに複数のパッチが含まれている場合は、コミットの単一の順次チェーン としてアップロードします。
  • ABI と KMI の配置: 複数のパッチのリスピンに、カーネル モジュール インターフェース（KMI）とアプリケーション バイナリ インターフェース（ABI）の更新（シンボルリストの変更や XML/STG ファイルの更新など）が含まれている場合は、これらのコミットをコミット チェーンの末尾に配置します。
  • リベース: チェーン内の親コミットを編集する場合は、ビルドの失敗を避けるため、親パッチの最新リビジョンの上にすべての子パッチをリベースする必要があります。
  • 競合の解決: パッチに競合マーカーがないことを確認します。
  • ビルドの検証: コミット チェーン全体が正常にビルドされる必要があります。

必須タグ

コミット メッセージに次のタグがない場合、リスピン リクエストの進捗はブロックされます。

  • Change-Id: 開発ブランチの変更の Change-Id と同一である必要があります。
  • Bug（既存）: 元の開発 ブランチのコミットからの既存の Bug: XYZ タグは削除しないでください。
  • Bug（リスピン）: 新しい Bug: XYZ タグを追加する必要があります。XYZ は、現在のリスピン リクエストに関連付けられたバグ ID に対応します。
  • 必要に応じて UPSTREAM コミットタグを更新します。開発ブランチからリリース ブランチに CL をチェリーピックし、CL に UPSTREAM のタグが付いている場合は、次のシナリオを考慮してください。
    • CL がリリース ブランチにクリーンに適用される場合は、追加の操作は必要ありません。
    • CL がクリーンに適用されない場合は、競合を修正し、 タグを BACKPORT に更新して、競合の解決の一部として行われた内容を文書化します。メインライン Linux からのバックポートの要件をご覧ください。

候補と ESRT

GKI チームが優先順位を付けられるように、リスピン リクエストに優先度（緊急度）を割り当てます。 この優先度により、GKI チームはより適切にかつタイムリーに パートナーをサポートできます。

  • 重大または時間的制約のあるリクエストの場合、優先度を P0 と設定します。
  • P0 と P1 のリクエストの場合、その緊急性も説明する必要があります。

次の表に、バグの優先度と解決までの時間 （ESRT）のマッピングを示します。

候補ESRT
P02 営業日
P15 営業日
P210 営業日
P315 営業日

SLA ポリシー

  • リリース ブランチごとに個別のリスピン リクエストを送信します。
  • 修正済みとしてマークされているリスピン リクエストに変更を加える場合は、新しいリスピン リクエストを送信します。リクエストを再び開いて別の変更リスト（CL）を追加しないでください。
  • リスピンのリクエストに返答が必要で、3 営業日以内に返答がなかった場合、優先度が 1 段階下がります（たとえば、P0 が P1 にダウングレードされます）。
  • 2 週間返信がない場合、バグは [修正しない] [（廃止）] としてマークされます。

リスピン リクエストを送信する

次の図は、リスピンのプロセスを示しています。プロセスは OEM パートナーによるリスピンのリクエストの送信から開始します。

緊急のリスピン プロセス 図 1.緊急のリスピン プロセス。

リスピン リクエストを送信するには:

  1. GKI リスピン リクエスト フォームに入力すると、すぐに Google の担当者に問い合わせできます。

    • このフォームにより、GKI リスピン リクエストのバグが作成されます。

  2. パッチを準備します。

    • パッチが GKI 開発ブランチに統合されていることを確認します。
    • 適切な GKI リリース ブランチにパッチを適用します。
    • チェリーピックしたパッチを修正して、リスピン リクエスト 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. バグを送信します。リクエストを送信すると、次のようになります。

    • 送信後の審査プロセス:

      • Google GKI チームはリクエストを審査し、それを承認するか、さらに情報が必要な場合はリクエスト者に再び割り当てます。
      • 修正が承認されたら、Google GKI チームは変更のコードレビューを実施します。この審査中は ESRT タイマーが有効になります。ただし、パッチが拒否された場合や、修正が必要な場合は、ESRT タイマーがリセットされます。
      • GKI チームが回帰の統合、ビルド、テストを行い、変更を認証します。

    • リリース: