プロダクト カーネルはデバイス カーネルまたは OEM カーネルとも呼ばれ、出荷するデバイスに搭載するカーネルです。GKI 以前は一連のアップストリームのカーネル変更からプロダクト カーネルを取得していました。図 1 ではどのようにしてカーネルへの追加によりプロダクト カーネル（OEM / デバイス カーネル）となるかを示しています。
図 1.GKI 以前のプロダクト カーネル コンストラクション
- kernel.org からの Linux 長期サポート（LTS）カーネルは Android 固有のパッチによって変更され、Android 共通カーネル（ACK）になります。
- ACK はベンダーによって変更され、システム オン チップ（SoC）のサポートが追加されます。ベンダーはパフォーマンスまたは電力の最適化を追加する場合もあります。その結果できるカーネルはベンダー カーネルと呼ばれます。
- 最後にベンター カーネルはさらに OEM により変更され、追加のデバイス ドライバと必要とされるカスタマイズが加えられます。その結果できるカーネルはプロダクト カーネルと呼ばれます。
これらすべての変更によって、カーネルコードの 50% もがアップストリームの Linux カーネルまたは ACK からではなく、ツリー外のコードになる場合があります。GKI 以前はほぼすべてのデバイスにカスタム カーネルがあり、カーネルの断片化を引き起こしていました。
断片化の代償
カーネルの断片化は、Android コミュニティに悪影響を及ぼします。
セキュリティ アップデートに手間がかかる
Android のセキュリティに関する公開情報（ASB）に記載されているセキュリティ パッチは、各デバイス カーネルにバックポートする必要があります。しかし、カーネルの断片化が原因で、実際に利用中の Android デバイスにセキュリティ修正を反映させるには膨大なコストがかかります。
長期サポートのアップデートの統合が困難
長期サポート（LTS）リリースには、セキュリティ修正やその他の重要なバグの修正が含まれています。LTS リリースを最新の状態に保つことは、セキュリティ修正を提供する最も効果的な方法であることが証明されています。Pixel デバイスにおいて、ASB でレポートされたカーネル セキュリティに関する問題の 90% が、最新の状態のデバイスではすでに修正されていることが判明しました。
しかし、デバイス カーネルのカスタム変更をすべて適用しても、LTS 修正をデバイス カーネルに統合することは困難です。
Android プラットフォーム リリースのアップグレードが妨げられる
断片化により、カーネルの変更を必要とする Android の新機能を、利用中のデバイスに追加することが困難になります。Android フレームワークのコードでは、最大 5 つのカーネル バージョンがサポートされ、新しいプラットフォーム リリースのカーネル変更が行われていないことを前提とする必要があります（Android 10 は 3.18、4.4、4.9、4.14、4.19 のカーネルをサポートしていますが、2017 年の Android 8 以降、新機能によって強化されていないものもあります）。
アップストリームの Linux にカーネル変更を反映することが困難
ほとんどのフラッグシップ デバイスは、カーネルに対する変更がすべて適用されて、18 か月以上前のカーネル バージョンで出荷されます。たとえば、4.14 カーネルは kernel.org によって 2017 年 11 月にリリースされましたが、4.14 カーネルを使用した最初の Android スマートフォンが出荷されたのは 2019 年春でした。
アップストリームのカーネル リリースとプロダクトの間のこうした大きな遅延のため、Android コミュニティが必要な機能とドライバをアップストリームのカーネルに組み込むことは困難です。
断片化の修正: 汎用カーネル イメージ
汎用カーネル イメージ（GKI）プロジェクトは、コアカーネルを統合し、SoC とボードのサポートをコアカーネルから読み込み可能ベンダー モジュールに移動することで、カーネルの断片化に対処しています。また、GKI はベンダー モジュール用に安定版のカーネル モジュール インターフェース（KMI）を提供しています。これにより、モジュールとカーネルを別々に更新できます。以下に、GKI カーネルの特徴をいくつか示します。
- GKI カーネルは ACK ソースからビルドされます。
- GKI カーネルは、単一カーネル バイナリに、アーキテクチャごと、LTS リリースごと（現時点では
android11-5.4およびandroid12-5.4用の arm64 のみ）の関連する読み込み可能モジュールを加えたものです。 - GKI カーネルは、関連する ACK でサポートされるすべての Android プラットフォーム リリースでテストされます。GKI カーネル バージョンの全期間を通じて、機能が非推奨になることはありません。
- GKI カーネルは、特定の LTS 内のドライバに対して安定版の KMI を公開します。
- GKI カーネルには、SoC 固有またはボード固有のコードは含まれません。
GKI アーキテクチャのイメージについては、カーネルの概要をご覧ください。
GKI は複雑な変更であり、Android 11 プラットフォーム リリースの v5.4 カーネル以降は、いくつかの段階を経てロールアウトされます。
現在、GKI には 2 つの段階があります。
- GKI 1.0 は、5.4 カーネルを搭載したデバイス向けに Android 11 で導入されました。GKI 1.0 は、5.4 カーネルを搭載したすべてのデバイスに適用されます。これには、Android 12 または Android 13 を搭載したデバイスも含まれます。
- GKI 2.0 は、5.10 カーネルを搭載したデバイス向けに Android 12 で導入されました。GKI 2.0 は、5.10 以降のカーネルを搭載したすべてのデバイス用の新しい標準です。
GKI 1.0
GKI 1.0 では、カーネル バージョン 5.4 を搭載したデバイスは、GKI テスト（Android 11 以降のプラットフォーム リリース）に合格する必要があります。GKI 1.0 の目標は次のとおりです。
- プロダクト カーネルを GKI カーネルに置き換える際に、ベンダー テストスイート（VTS）または互換性テストスイート（CTS）で回帰を防止する。
- パートナーが AOSP 共通カーネルを使用してカーネルを最新の状態に保つ負担を軽減する。
- 新しい Android リリースでアップグレードしてリリースするデバイスのために、Android の重要な変更をカーネルに追加する。
- Android ユーザー空間を壊さないようにする。
- ハードウェア固有のコンポーネントを読み込み可能モジュールとしてコアカーネルから分離する。
GKI 1.0 のドキュメントについては、GKI 1.0 のセクションをご覧ください。
GKI 2.0
GKI 2.0 では、カーネル バージョン 5.10 以降を搭載したデバイスは、GKI カーネル（Android 12 以降）を搭載して出荷する必要があります。署名付きブートイメージが利用可能であり、LTS と重要なバグ修正で定期的に更新されます。KMI 用にバイナリの安定性が維持されるため、ベンダー イメージを変更しなくても、このようなブートイメージをインストールできます。GKI 2.0 の目標は次のとおりです。
- プロダクト カーネルを GKI カーネルに置き換える際に、パフォーマンスまたは電力の大幅な低下が発生しないようにする。
- ベンダーの関与なしでパートナーがカーネルのセキュリティ修正とバグ修正を提供できるようにする。
- デバイスのメジャー カーネル バージョンの更新（例: v5.10 から 2021 LTS カーネルへの更新）のコストを削減する。
- アップグレードの明確なプロセスを定めてカーネル バージョンを更新することにより、アーキテクチャごとに単一の GKI カーネル バイナリを保持する。
GKI 2.0 は、Android カーネルの最新の状態を表します。カーネルのドキュメントには、GKI 1.0 と以前のカーネル（4.19 以前）のサブセクションを除いて、GKI 2.0 のアーキテクチャが反映されています。