このページは Cloud Translation API によって翻訳されました。

Generic Kernel Image（GKI）リリースプロセス

このドキュメントでは、Android 12用のGKIv5.10がどのようにリリースされるかについて説明します。これには、毎週、毎月、および帯域外の緊急リリースが含まれます。このドキュメントの目的は、GKIを入手する場所と、帯域外の緊急修正のプロセスに関するガイドラインをOEMに提供することです。 OEMは、 GKI開発ガイドを使用して、Androidカーネルチームと協力して製品のGKIカーネルを最適化する方法について詳しく知ることもできます。

GKIリリースケイデンス

GKIは、2021年7月14日から始まるKMIフリーズ後の月次ケイデンスでリリースされます。次の図は、リリーススケジュールのケイデンスを示しています。

GKIマンスリー認定ビルド	チェックイン締切日	GKIプリロード準備日	ラベル	確認済み？
7月（KMIフリーズ）	2021年7月14日	7月末	Android 12 AOSP認定ビルド-7月	はい
8月	2021年8月16日	8月末	Android 12 AOSP認定ビルド-8月	はい
9月	2021年9月17日	9月末	Android 12 AOSP認定ビルド-9月	はい
10月	2021年10月15日	2021年10月29日	Android 12 AOSP認定ビルド-10月	はい
11月	2021年11月12日	2021年11月30日	Android 12 AOSP認定ビルド-11月	はい
12月	2021年12月10日	2021年12月22日	Android 12 AOSP認定ビルド-12月	はい
1月	2022年1月14日	2022年1月31日	Android 12 AOSP認定ビルド-1月	はい
2月	2022年2月14日	2022年2月28日	Android 12 AOSP認定ビルド-2月	はい
行進	2022年3月16日	2022年3月31日	Android 12 AOSP認定ビルド-3月	はい
4月	2022年4月15日	2022年4月29日	Android 12 AOSP認定ビルド-4月	はい
5月	2022年5月16日	2022年5月31日	Android 12 AOSP認定ビルド-5月	はい
六月	2022年6月15日	2022年6月30日	Android 12 AOSP認定ビルド-6月	はい
7月	2022年7月15日	2022年7月29日	Android 12 AOSP認定ビルド-7月	はい
8月	2022年8月15日	2022年8月31日	Android 12 AOSP認定ビルド-8月	はい
9月	2022年9月16日	2022年9月30日	Android 12 AOSP認定ビルド-9月	はい
10月	2022年10月14日	2022年10月31日	Android 12 AOSP認定ビルド-10月	はい
11月	2022年11月14日	2022年11月30日	Android 12 AOSP認定ビルド-11月	はい
12月	2022年12月9日	2022年12月21日	Android 12 AOSP認定ビルド-12月	はい

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

OEMは、最近リリースされたAndroidGKIを使用できます。 OEMは、Android Security Bulletin（ASB）のLTS要件に準拠している限り、GKI認定ビルドで起動できます。

認定ビルドリスピンポリシー

GKI認定のバイナリは、ASBのLTS要件に準拠しなくなった後は、再スピンがサポートされなくなります。たとえば、 android12-5.10-2021-11ブランチ（5.10.66）は、2022年11月以降のリスピンではサポートされていません。これは、 android12-5.10-2021-11ブランチ（5.10.66）がのLTS要件に準拠していないためです。 ASB-2022-11。
詳細については、緊急リスピンプロセスを参照してください。

毎週の開発リリース

リリースはイカでテストされ、最低品質のバーに合格していることを確認します。

GKIバイナリは、変更がマージされるときにci.android.comからセルフサービスで利用できます。ウィークリービルドは認定されませんが、開発とテストのベースラインとして使用できます。ウィークリービルドは、エンドユーザー向けの実稼働デバイスのビルドには使用できません。

毎月の認定リリース

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

毎月、GKIの月次リリース候補（認定されていない）がチェックインの締め切り日後に選択されます。これは通常、その月の2番目の週次ビルドです。月次リリース候補が選択された後、その月のリリースに新しい変更は受け入れられません。クローズウィンドウ期間中は、テストの失敗の原因となるバグの修正のみに対処できます。リリース候補は、 GKI認定のセクションで説明されているように、品質保証を受けて、参照デバイスとイカを使用したGSI+GKIビルドでコンプライアンステストに合格することを確認します。

GKIリリースケイデンスタイムライン図1.GKIリリースのタイムライン

緊急リスピンプロセス

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

OEMは、問題をブロックしている技術承認（TA）のためにカーネルを再スピンする必要がある場合があります。リスピンは、毎月の認定リリースビルドでサポートされており、米国のタイムゾーンでは2営業日の予想標準解決時間（ESRT）があります。

ESRTは、GKIチームによって承認され、影響を受けるOEMによってレビューされている限り、修正を含む認定GKIバイナリを配信するのにかかる時間として定義されます。 ESRTは推定値であり、保証として解釈されるべきではありません。

TAブロッキング修正の再スピンが必要なOEMは、次のことを行う必要があります。

Issue Trackerにバグを報告し、すぐにGoogleの連絡先に連絡してください。
- すでに修正が行われている場合、バグはAOSPで提出されたパッチを指しているはずなので、Googleはそれを確認できます。パッチを送信できない場合は、パッチをテキストファイルとしてIssueTrackerのバグに添付してください。
- まだ修正がない場合は、カーネルのバージョン番号やログなど、バグにできるだけ多くの情報を含める必要があります。これにより、Googleが問題のデバッグを支援できるようになります。
修正が合意された後、Google GKIチームコードは変更をレビューし（CR + 2）、リグレッションをテストします。テストはESRTカウントダウンを開始し、バイナリがci.android.comに公開されたときに終了します。

GKI資格

GKIビルドの種類	品質の実施	ノート
毎週	イカのテストブート VTSのサブセット CTSのサブセット	認定されていません。テストとデバイスが起動します。デバイスの起動には使用できません。
毎月（認定済み）	イカのテストブート VTS CTS 参照ハードウェアテストブート VTS CTS
リスピン（認定済み）	イカのテストブート VTS CTSのサブセット参照デバイスのテストブート VTS	GKI認定ビルドの上に構築されています。ビルドは、認定後に認定されます。

GKIビルドの種類

品質の実施

ノート

毎週

イカのテスト

ブート
VTSのサブセット
CTSのサブセット

認定されていません。テストと
デバイスが起動します。
デバイスの起動には使用できません。

毎月（認定済み）

イカのテスト

ブート
VTS
CTS

参照ハードウェアテスト

ブート
VTS
CTS

リスピン（認定済み）

イカのテスト

ブート
VTS
CTSのサブセット

参照デバイスのテスト

ブート
VTS

GKI認定ビルドの上に構築されています。
ビルドは、認定後に認定されます。

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

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

Android継続的インテグレーションダッシュボードのテスト結果など、CIに関する詳細情報を見つけることができます。

よくある質問

すでにリリースされているGKIに基づいて新しいGKIバイナリを構築することは可能ですか？

はい、これはリスピンとして知られています。リリースされたGKIビルド（再スピンが要求される）がAndroid Security Bulletin（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/デバイス/モデルに固有であると判断した場合、GKIチームは、変更によって追加されたコードが影響を受けるデバイス/モデル/SKUでのみ実行されるようにすることができます。

統合されたリスピンの主な利点は、同じリリースベースを使用しているすべてのデバイスが互いにメリットを享受できることです。特に、発見したバグが一般的ですべてのユーザーに適用できる場合はそうです。保因者検査で見つかったコアカーネルのバグは、この概念の具体例です。

GoogleがOEMパッチと問題シナリオに関する特定の情報を提供し、OEMが自社製品にパッチを実装することの影響とリスクを評価できるようにする状況はありますか？

問題が理解され、すべての詳細が収集されるまで、Googleはリスピンビルドに変更を追加しません。これは、変更ログ（コミットメッセージ）に表示されます。 Googleは、影響を受ける特定のデバイスを明らかにしていませんが、OEMは、変更ログで問題の説明と解決策をいつでも見つけることができます。