Android 共通カーネル

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

AOSP 共通カーネル（Android 共通カーネルまたは ACK とも呼ばれます）は kernel.org カーネルのダウンストリームであり、メインラインまたは長期サポート（LTS）カーネルにはマージされていないものの Android コミュニティにとって関心のあるパッチが含まれています。たとえば以下のようなパッチがあります。

• Android 機能に必要なアップストリーム機能のバックポートと cherry-pick
• Android デバイス向けには準備が整っているが、まだ開発アップストリームにある機能
• ベンダーや OEM の機能であるが、他のエコシステム パートナーにも有用なもの

android-mainline は Android 機能向けの主要開発ブランチです。リーナス トーバルズ氏がリリースまたはリリース候補を掲載すると、その都度 Linux メインラインが android-mainline にマージされます。2019 年まで、Android 共通カーネルは、新たに宣言された LTS カーネルのクローンを作成して Android 固有のパッチを追加することで作成されました。このプロセスは 2019 年に変更され、新しい Android 共通カーネルが android-mainline から分岐しました。この新しいモデルでは、同じ結果を段階的に実現することによって、ポート転送と Android パッチのテストを行う労力が大きく削減されます。android-mainline には大規模な継続的テストが実施されます。このモデルにより、公開されたその日から高品質のカーネルが確保されます。

新しい LTS がアップストリームで宣言されると、対応する共通カーネルが android-mainline から分岐します。これにより、パートナーは android-mainline からのマージを行うことで、LTS バージョンの宣言より前にプロジェクトを開始できます。新しい共通カーネル ブランチが作成された後は、シームレスにマージソースを新しいブランチに変更できます。

他の共通カーネル ブランチには、関連する LTS カーネルからの定期的なマージが実施されます。これらのマージは通常、LTS リリースが掲載された直後に行われます。たとえば、Linux 6.1.75 が掲載されたときは、6.1 共通カーネル（android14-6.1）に統合されました。パートナーは、カーネルを更新して LTS と Android 固有の最新のバグ修正を常に適用しておくことが強く推奨されます。

ACK KMI カーネル ブランチ

GKI カーネルは、安定版のカーネル モジュール インターフェースを備えています。KMI はカーネル バージョンと Android プラットフォーム リリースによって一意に識別されるため、ブランチは ANDROID_RELEASE-KERNEL_VERSION という名前になります。たとえば、Android 14 用の 6.1 GKI カーネルは android14-6.1 という名前になります。Android 15 向けに、GKI カーネル android15-6.6 が導入されました。

機能カーネルとローンチ カーネル

Android 15 以前は、最新の 3 つのカーネルのいずれかをデバイスのローンチに使用できました。Android 15 以降は、最新の 2 つのカーネル バージョンをデバイスのローンチに使用できます。Android 15 用のローンチ カーネルは android15-6.6 および android14-6.1 です。

プラットフォーム リリースのアップデート時にカーネルをアップグレードする必要はないため、プラットフォーム リリースの最新機能が存在しないカーネルでもデバイスのローンチに使用できます。したがって、プラットフォーム リリースを Android 15 にアップグレードした後でも、Android 14 用に設計されたカーネル（android14-6.1 など）を引き続きデバイスで使用できます。

共通カーネルの階層

android-mainline からのブランチ

共通カーネル階層のトップレベルを図 1 に示します。

図 1:android-mainline カーネルからの共通カーネルの作成

新しい Android 共通カーネル android14-6.1 は、2022 年に android-mainline から分岐しました。2023 年に次の LTS が宣言されると、android15-6.6 が android-mainline から分岐しました。

図 1 に示すように、各カーネル バージョンは 2 つの GKI カーネルの基礎となります。たとえば、2 つの v5.15 カーネルは android13-5.15 と android14-5.15 で、どちらもそれぞれのプラットフォーム リリースの機能カーネルです。5.10 の場合も同様に、LTS が宣言されたときに android12-5.10 が作成され、2021 年春にカーネル機能の完全実装のマイルストーンに到達すると android13-5.10 が android12-5.10 から分岐して、Android 13 向けの機能の開発が可能になりました。Android 15（2024）以降は、各カーネル バージョンにつき 1 つの新しい GKI カーネルのみとなります（android15-6.1 カーネルはありません）。

ACK KMI ブランチのライフサイクル

ACK KMI ブランチのライフサイクルを図 2 に示します。

図 2. 6.6 ACK KMI ブランチのライフサイクル

開発プロセスとブランチのライフサイクルを明確にするために、図 2 は 6.6 の ACK KMI ブランチに焦点を当てています。

各 ACK KMI ブランチは、図 2 において各ブランチで異なる色によって示されている 3 つのフェーズを繰り返します。上記のように、LTS は、フェーズに関係なく定期的にマージされます。

開発フェーズ

作成された ACK KMI ブランチは開発フェーズ（図 2 では dev）に入り、Android プラットフォームの次期リリースに向けて機能の提案や提出を受け付けます。図 2 では、6.6 が新しいアップストリーム LTS カーネルとして宣言されたときに、android15-6.6 が作成されています。

安定化フェーズ

ACK KMI ブランチは、機能の完全実装が宣言されると、安定化フェーズ（図 2 では stable）に入ります。パートナー機能とバグ修正は引き続き受け入れられますが、インターフェースに影響する変更を検出するために KMI トラッキングが有効になります。このフェーズでは、KMI の互換性を損なう変更が受け入れられ、事前に決められた頻度で KMI 定義が更新されます（通常は 2 週間ごと）。KMI モニタリングの詳細については、GKI の概要をご覧ください。

KMI 固定フェーズ

新しいプラットフォーム リリースが AOSP にプッシュされる前に、ACK KMI ブランチが固定され、ブランチのライフタイム期間はこの状態が維持されます。つまり、基本的に KMI の互換性を損なう変更は受け入れられません。ただし、安定版の KMI に影響を及ぼさずに対処することが不可能な重大なセキュリティ問題が特定された場合は、その限りではありません。KMI の互換性が損なわれるのを避けるため、Android デバイスの修正が必要でなければ、LTS からマージされたパッチが変更または削除される場合があります。

ACK KMI ブランチが固定されている場合、バグ修正とパートナー機能は、既存の KMI 共通カーネルの互換性が損なわれない範囲であれば受け入れられます。現在の KMI を構成するインターフェースに影響が及ばないのであれば、新しくエクスポートされたシンボルで KMI を拡張できます。新しいインターフェースが KMI に追加されると、すぐに安定化し、今後の変更によって互換性が損なわれることがなくなります。

たとえば、KMI インターフェースの共通カーネルで使用される構造にフィールドを追加しようとしても、インターフェース定義が変更されるため許可されません。

struct foo {
  int original_field1;
  int original_field2;
  int new_field;  // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_stuff(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

ただし、新しい関数の追加は可能です。

struct foo2 {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo2 &myarg)
{
  do_stuff2(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

GKI カーネルのライフタイムを通じて、ユーザー空間との下位互換性が維持されるので、KMI カーネルはデバイスがローンチされる Android プラットフォーム リリースに安全に使用できます。以前のリリースに対して継続的なテストを実施することで、互換性の維持が確保されます。そのため、図 2 では、Android 15 デバイスとそれ以降のデバイスに android15-6.6 カーネルを使用できます。Android プラットフォーム リリースは以前のバージョンとも互換性があるため、android14-6.1 カーネルは Android 15 デバイスのローンチとアップグレードに使用できます。

KMI 世代番号

安定化フェーズの間に LTS マージが行われる場合や、このマージの後に KMI 変更パッチの受理を必要とするセキュリティの問題やその他のイベントが発生した場合は、build.config.common で記録される KMI 世代番号が上がります。現在の KMI 世代は uname コマンドを使用して確認できます。

$ uname -r
6.6.30-android15-6-g86d10b30f51f

プラットフォーム リリースの後の数字は KMI 世代を表します（この場合は 6）。

KMI 世代が変更された場合、以前の KMI 世代に適合したベンダー モジュールとの互換性がカーネルになくなるため、モジュールをビルドし直して、カーネルと同期する状態に更新する必要があります。KMI が固定されると、KMI 世代が変更されることは、きわめてまれです。

カーネル間の互換性

新しい GKI カーネルから、同じ LTS ファミリー内のカーネル間の互換性要件が変更されます。

GKI カーネル

GKI カーネルは、カーネル バージョンをサポートしていたすべての Android プラットフォーム リリースとの下位互換性を維持します。また、Android プラットフォーム リリースは、以前のリリースの GKI カーネルとの下位互換性があります。そのため、Android 14（2023）用に開発された android14-6.1 カーネルは、Android 15（2024）を実行するデバイスで安全に使用できます。互換性は、サポートされているすべてのリリースで GKI カーネルの継続的な VTS テストと CTS テストを行うことで検証されています。

KMI は安定版であるため、ベンダー イメージ内のカーネル モジュールをビルドし直さなくてもカーネルを更新できます。

KMI 互換性は、異なる GKI カーネル間では維持されません。そのため、たとえば android14-6.1 カーネルを android15-6.6 カーネルに置き換えるには、すべてのモジュールを再ビルドする必要があります。

GKI カーネルは、初回とそれ以降のリリースでのみサポートされます。また、古いリリースではサポートされていません。したがって、Android 14（2023）を実行するデバイスでは android15-6.6 カーネルはサポートされていません。

互換性マトリックス

次の表に、各 Android プラットフォーム リリースでサポートおよびテストされているカーネル バージョンを示します。

サポート期間とセキュリティ パッチ

ACK はアップストリームからの LTS マージと Android 固有のコードのバグ修正を受け取ります。この修正には、ACK に関連する毎月の Android のセキュリティに関する公開情報に掲載されるカーネル セキュリティ パッチがすべて含まれます。

ACK は、kernel.org の対応するアップストリームの安定版カーネルよりも長くサポートされる可能性があります。この場合、Google はこのセクションに記載されているサポート終了（EOL）日まで延長サポートを提供します。カーネルのサポートが終了すると、Google によるサポートも終了し、そのカーネルを実行しているデバイスは脆弱であるとみなされます。

カーネル 6.6 以降、安定版カーネルのサポート期間は 4 年です。

この表は、サポートされている ACK の有効期間を示しています。

共通カーネルのテスト

共通カーネルは、ベンダーによるダウンストリーム テストに加えて、いくつかの CI システムでテストされます。

Linux カーネル機能テスト

Linux カーネル機能テスト（LKFT）によって、一連の物理的 arm32 および arm64 デバイス上で、kselftest、LTP、VTS、CTS などのさまざまなテストスイートが開始されます。最近のテスト結果については、こちらをご覧ください。

KernelCI テスト

KernelCI ビルドアンドブート テストは、共通カーネル ブランチに新しいパッチが commit されるたびに開始されます。さまざまなボードで、数百種類のビルド構成がテストされ起動されます。Android カーネルの最近の結果はこちらで確認できます。

Android の presubmit テストと postsubmit テスト

presubmit テストは、Android 共通カーネルにエラーが入り込むのを防ぐために使用されます。テスト結果の概要は、Android 共通カーネル Gerrit のコード変更の [Checks] タブにあります。

ci.android.com で Android 共通カーネル ブランチに新しいパッチがコミットされると、Android 共通カーネル ブランチの新しい公開ビルドに対して Android の postsubmit テストが実行されます。ci.android.com でブランチ名の一部として aosp_kernel を入力すると、結果を利用できるカーネル ブランチのリストが表示されます。たとえば、android-mainline の結果はこちらで確認できます。特定のビルドをクリックすると、Test Results タブでテスト結果を確認できます。

Android プラットフォームのソースツリーでテストグループ kernel-presubmit を使用するテスト マッピングによって定義されたテストは、Android カーネル ブランチの presubmit として実行されます。たとえば、test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING にある以下の構成では、Android 共通カーネルコードのチェックイン時に vts_kernel_proc_file_api_test を presubmit テストとして有効にします。

{
  "kernel-presubmit": [
    {
      "name": "vts_kernel_proc_file_api_test"
    }
  ]
}

ゼロデイテスト

ゼロデイテストでは、新しいパッチが commit されたときに、すべての Android 共通カーネル ブランチに対してパッチごとのテストが実施されます。さまざまなブートテスト、機能テスト、パフォーマンス テストが実行されます。公開グループ cros-kernel-buildreports に参加する

テスト マトリックス

Android 共通カーネルに対するコントリビューション

一般に、機能の開発は Android 共通カーネルではなくメインライン Linux で行います。アップストリームでの開発を強くおすすめします。開発が承認された後は、必要に応じて特定の ACK ブランチに簡単にバックポートできます。Android カーネルチームは、Android エコシステムの利益のために、アップストリームの取り組みを積極的にサポートします。

Gerrit にパッチを送信し、これらの改善協力ガイドラインに従ってください。