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

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

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

利用資格とライフサイクル

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

パッチの送信標準

リスピン リクエストの処理の想定標準解決時間（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 と同一である必要があります。
    • 例外: パッチが LTS アップデートの一部として開発ブランチにマージされた場合、LTS バージョンのチェリーピックであり、UPSTREAM パッチとしてフォーマットされている必要があります。Android 共通カーネルにパッチを送信する方法をご覧ください。
  • 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 チームが回帰の統合、ビルド、テストを行い、変更を認証します。

    • リリース: