汎用カーネル イメージ（GKI）リリース プロセス

このページでは、GKI のリリースの形式（週次、月次、帯域外緊急リリースなど）について説明します。このドキュメントの目的は、GKI を利用できる場所と、帯域外緊急修正プロセスについてのガイドラインを OEM に提供することです。OEM は GKI 開発を参照して、Android カーネルチームと協力し、自社の製品に合わせて GKI カーネルを最適化する方法の詳細を確認することもできます。

GKI のリリース頻度

GKI は KMI 固定の後に毎月 1 回の頻度でリリースされます。

Android 13、14、15 の GKI リリース

この表は android13-5.10、android13-5.15、android14-5.15 にのみ適用されます。

GKI 月次認定ビルド チェックインの締め切り日 GKI プリロード準備完了日 確認済み？
11 月 2024 年 11 月 11 日 2024 年 11 月 27 日 ○
1 月 2025 年 1 月 17 日 2025 年 1 月 31 日 ○
3 月 2025 年 3 月 14 日 2025 年 3 月 31 日 ○

この表は android14-6.1、android15-6.6 にのみ適用されます。

GKI 月次認定ビルド チェックインの締め切り日 GKI プリロード準備完了日 確認済み？
10 月 2024 年 10 月 1 日 2024 年 10 月 14 日 ○
11 月 2024 年 11 月 1 日 2024 年 11 月 15 日 ○
12 月 2024 年 12 月 2 日 2024 年 12 月 16 日 ○
1 月 2025 年 1 月 6 日 2025 年 1 月 22 日 ○

Android 12 GKI リリース

2024 年 5 月以降、android12-5.10 GKI リリースは四半期ごとに行われ、月の半ばに公開されます。この表は android12-5.10 にのみ適用されます。

GKI 月次認定ビルド チェックインの締め切り日 GKI プリロード準備完了日 確認済み？
11 月 2024 年 11 月 1 日 2024 年 11 月 15 日 ○
2 月 2025 年 2 月 3 日 2025 年 2 月 17 日 ○

OEM 向けの GKI ビルドの有効性

OEM は、最近リリースされた Android GKI を使用できます。OEM は、Android のセキュリティに関する公開情報（ASB）の LTS 要件を満たしていれば、GKI 認定ビルドで起動できます。

週次開発リリース

リリースは Cuttlefish でテストされ、最低品質基準を満たしていることが確認されます。

変更が統合されると、GKI バイナリを Android CI からセルフサービスで使用できます。週次ビルドは認定されませんが、開発とテストのベースラインとして使用できます。エンドユーザー向けの製品版デバイスのビルドに、週次ビルドを使用することはできません。

月次認定リリース

GKI 月次リリースには、テスト済みの boot.img が含まれています。この中には、バイナリが既知のソースコード ベースラインから構築されたことを証明する、Google による証明書が含まれています。

毎月、チェックインの締め切り日（通常はその月の 2 回目の週次ビルド）後に GKI の月次リリース候補版（未認定）が選択されます。月次リリース候補版が選択された後の新しい変更はその月のリリースに受け入れられません。クローズド ウィンドウ期間中は、テスト失敗を引き起こすバグのみを修正できます。リリース候補は、GKI の認定セクションに記載されているように、リファレンス デバイスと Cuttlefish が組み込まれた GSI+GKI ビルドでコンプライアンス テストに合格するように、品質評価の対象となります。

GKI リリースの頻度のタイムライン 図 1. GKI リリースのタイムライン

緊急のリスピン プロセス

リスピンとは、GKI カーネルの公開リリース後のバイナリの再統合、再ビルド、再テスト、再認定のプロセスを指します。次のような場合に、認定バイナリのリスピンをリクエストできます。

  • シンボルリストを更新する場合。
  • 携帯通信会社のラボ承認中に見つかったバグを含め、バグに修正を適用する場合。
  • ベンダーフックを追加する場合。
  • 既存の機能にパッチを適用する場合。
  • セキュリティ パッチを適用する場合（6 か月後）。

セキュリティ パッチは、ブランチがリリースされてから最大 6 か月間、リリース ブランチに自動的に統合されます。6 か月を過ぎると、ブランチにセキュリティ パッチを適用するためには、リスピンをリクエストする必要があります。

リスピン リクエスト ガイドライン

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

  • リスピンは、月次ビルドの最初の公開リリース後のリリース ブランチでのみ許可されます。

  • リスピンのリクエストは、最初の公開リリースから最大 6 か月間、特定のリリース ブランチに対してのみ受け付けられます。6 か月間の経過後は、ブランチは Android のセキュリティに関する公開情報に記載されているセキュリティ パッチについてのみ、リスピンの対象となります。

  • Android のセキュリティに関する公開情報（ASB）で定義される LTS 要件が原因でブランチが準拠しなくなると、そのブランチは非推奨になります。非推奨のブランチに対するリスピン リクエストは受け入れられません。特定の GKI リリース ブランチが非推奨になる日は、リリースの月次 GKI リリースビルド ノートに記載されます。今後、LTS 要件は毎年 5 月と 11 月に更新予定です。たとえば、android12-5.10-2023-07 ブランチ（5.10.177）は ASB-2024-05 の LTS 要件を遵守していないため、android12-5.10-2023-07 ブランチ（5.10.177）は 2024 年 5 月 1 日より後のレスピンではサポートされていません。

  • リスピンは、緊急のバグの修正、シンボルリストの更新、既存機能の修正のためにパッチを適用する場合にのみ適用されます。

  • 月次リリース ブランチに入るすべてのパッチは、すでにメインの GKI 開発ブランチに統合されている必要があります。たとえば、android12-5.10-2022-09 のリスピンにパッチが必要な場合、すでに android12-5.10 に統合されている必要があります。

  • メインの GKI 開発ブランチからパッチをチェリーピックして、そのパッチを毎月のリリース ブランチにアップロードする必要があります。

  • リスピンのリクエストでは、リクエストに優先度（緊急度）を割り当てる必要があります。この優先度により、GKI チームはより適切にかつタイムリーにパートナーをサポートできます。重大または時間的制約のあるリクエストの場合、優先度を P0 と設定します。P0 と P1 のリクエストの場合、その緊急性も説明する必要があります。次の表に、バグの優先度と解決時間（ESRT）のマッピングを示します。

    優先度 ESRT
    P0 2 営業日
    P1 5 営業日
    P2 10 営業日
    P3 15 営業日

  • リリース ブランチごとに個別のリスピン リクエストを送信する必要があります。たとえば、android12-5.10-2022-08 と android12-5.10-2022-09 の両方にリスピンが必要な場合、2 つのリスピン リクエストを作成する必要があります。

  • ビルドが提供され、リスピン リクエストが修正済みとしてマークされると、リスピン リクエストを再び開いて別の CL を追加することはできません。統合を必要とする追加パッチがある場合、新しいリスピン リクエストを送信する必要があります。

  • 検討中の各 CL で、次のタグを追加します。

    • Bug: 各 CL のコミット メッセージにバグ ID を追加する必要があります。
    • Change-Id: ベースブランチ変更の Change-Id と同一である必要があります。

  • リスピンのリクエストに OEM からの返信が必要で、3 営業日以内に返信がなかった場合、優先度が 1 段階下がります（たとえば、P0 が P1 にダウングレードされます）。2 週間以内に OEM からの返信がない場合、そのバグは修正なし（サポート終了）としてマークされます。

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

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

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

リスピン プロセスを開始する手順は以下のとおりです。

  1. GKI リスピン リクエスト フォームに入力すると、すぐに Google テクニカル アカウント マネージャーに問い合わせできます。このフォームにより、GKI リスピン リクエストのバグが作成されます。リスピン リクエストのバグが、リクエストした人、GKI チーム、バグの CC リストに追加した特定の個人に表示されます。
    • すでに修正がある場合は、AOSP でパッチを提出し、Google が確認できるようにします。パッチの送信が不可能な場合は、そのパッチをテキスト ファイルとしてリクエストに添付する必要があります。
    • まだ修正がない場合、カーネル バージョン番号やログなど、可能な限り多くの情報をリクエストに含める必要があります。これらの情報は Google が問題をデバッグするのに役立ちます。
  2. Google GKI チームはリクエストを審査し、それを承認するか、さらに情報が必要な場合はリクエスト者に再び割り当てます。
  3. 修正が承認されたら、Google GKI チームは変更のコードレビュー（CR+2）を実施します。審査から ESRT 期間が開始します。GKI チームが回帰の統合、ビルド、テストを行い、変更を認証します。
  4. バイナリが ci.android.com にリリースされます。ESRT 期間が終了し、Google GKI チームがリクエストを修正済みとしてマークし、リスピンのビルドを参照します。リスピンのビルドは、汎用カーネル イメージ（GKI）リリースビルド ページにも掲載されます。

GKI の評価

GKI ビルドのタイプ 品質管理 注
週次 Cuttlefish のテスト
  • 起動
  • VTS のサブセット
  • CTS のサブセット
  • 認定なしテストと
    デバイスの起動のみ。
  • デバイスの起動には使用できません。
月次（認定） Cuttlefish のテスト
  • 起動
  • VTS
  • CTS
リファレンス ハードウェア テスト
  • 起動
  • VTS
  • CTS
リスピン（認定） Cuttlefish のテスト
  • 起動
  • VTS
  • CTS のサブセット
リファレンス デバイス テスト
  • 起動
  • VTS
  • GKI 認定ビルドを基に作成されます。
  • ビルドは評価後に認定されます。

ビルド アーティファクトを入手できる場所

すべてのリリースのアーティファクトは ci.android.com から入手できます。

テスト結果など、CI の詳細については、Android 継続的インテグレーション ダッシュボードをご覧ください。

よくある質問

ここでは、GKI のリリース プロセスについてのよくある質問をいくつかご紹介します。

すでにリリースされている GKI に基づいて新しい GKI バイナリを作成することはできますか？

はい。これは「リスピン」と呼ばれます。リリースされた GKI ビルド（リスピンがリクエストされたもの）が Android のセキュリティに関する公開情報（ASB）の LTS 要件を満たしていれば、リスピンのプロセスはサポートされます。

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

GKI アーティファクトのコピーは out/.../dist から入手できます。

GKI バイナリ（緊急スピンパッチを含む）は、最新のコードベースでビルドされていますか？

いいえ。リスピンには、選択された月次認定カーネル上のパッチのみが含まれます。これらのリスピンには、該当する基本月次リリースを使用して特定の期間に OEM が報告したすべてのリリース ブロックのバグの修正が含まれています。このような状況が発生する例を次に示します。

  • OEM1 と OEM2 は、2021 年 11 月から GKI バイナリ リリースを使用することを決定しました。
  • OEM1 と OEM2 は、サポートにパッチが必要な問題を見つけました。これらのパッチは異なる場合もあれば、同じ場合もあります。
  • 2021 年 11 月バイナリへのリスピン時に、リスピン ウィンドウ中に OEM1 と OEM2 の両方から報告された起動のブロックの修正がありますが、他の修正はありません。
  • 2 番目の項目に記載されている問題は、それ以降の GKI 月次リリースにも記載されます。

10 月のリスピンには OEM が提出したパッチがすべて含まれていますが、それ以外の OEM パッチは、当社の製品を使用してのテストが実施されていないため、当社に影響があります。自社のパッチのみを含めることはできますか？

できません。「OEM ごと」のリスピンパスは拡張できません。その代わりに、GKI チームは、リスピンビルドに適用するすべての変更を精査し、使用可能なすべてのハードウェアで変更をテストしてから新しいビルドを作成します。GKI チームは、問題が OEM、デバイス、モデルに特有のものであると判断した場合、変更によって追加されたコードが、影響を受けるデバイス、モデル、SKU でのみ実行されることを確認できます。

統合リスピンによって得られる主なメリットは、同じリリースベースを使用しているすべてのデバイスで相互に利点があることです。特に、発見されたバグが一般的なもので、すべてのユーザーに該当する場合に大きな利点があります。このコンセプトの具体例としては、携帯通信会社のテストで見つかるコアカーネルのバグがあげられます。

OEM が製品にパッチを実装することで生じる影響とリスクを評価できるように、Google が OEM のパッチに関する具体的な情報や問題のシナリオを提供することはありますか？

問題を把握してすべての詳細が収集されるまで、Google はリスピンビルドに変更を加えません。これは変更ログ（コミット メッセージ）で確認できます。Google は、どのようなデバイスで影響が生じるかを明らかにしていませんが、OEM は変更ログで問題の説明と解決策をいつでも確認できます。