ベンダー モジュール用の安定版のカーネル モジュール インターフェース（KMI）の維持は不可欠です。GKI カーネルはバイナリ形式でビルドおよび出荷され、ベンダーが読み込み可能なモジュールは別のツリーでビルドされます。生成される GKI カーネルとベンダー モジュールは、同時に同じツリーでビルドされたかのように動作する必要があります。
一般に、Linux コミュニティはメインライン カーネルのカーネル内 ABI の安定性という概念に難色を示してきました。さまざまなツールチェーン、構成、進化し続ける Linux メインライン カーネルに対応して、メインラインで KMI の安定性を維持することは不可能です。ただし、次のような高度な制約が設定された GKI 環境では、安定した KMI を維持できます。
カーネルのビルドに使用できる構成が
gki_defconfig1 つのみであること。KMI の安定性は、
android13-5.10、android12-5.10、android13-5.15など、同じ LTS と Android バージョンのカーネル内でのみ維持すること。android-mainlineについては、KMI の安定性を維持しないこと。
カーネルとモジュールのビルドには、AOSP で提供され、対応するブランチに対して定義された特定の Clang ツールチェーンのみを使用すること。
シンボルリストで指定されたモジュールで使用することがわかっているシンボルのみの安定性をモニターし、KMI シンボルとみなすこと。
- 必然的にベンダー モジュールは KMI シンボルのみを使用すること。この制約は、KMI 以外のシンボルを必要とする場合にモジュールを読み込まないようにすることで適用されます。
KMI ブランチを固定した後でも変更は可能だが、KMI の互換性を損なう変更はしないこと。KMI の互換性を損なう変更には、次のようなものがあります。
- 構成の変更
- カーネルコードの変更
- ツールチェーンの変更（アップデートを含む）
密閉型のビルドプロセスと LLVM ツールチェーンの使用
密閉型のビルドプロセスでは、kernel/manifest 内の repo マニフェストにビルド環境を完全に記述することにより、安定した KMI が確保されます。たとえば、android13-5.15 のマニフェストには、ツールチェーン、ビルド スクリプトなど、汎用カーネル イメージ（GKI）カーネルのビルドに必要なすべてのものが含まれています。GKI ビルド構成 build.config.gki.aarch64 などのそれぞれの build.config 構成ファイルにより、含まれているツールが正しく使用され、一貫したビルド結果が生成されます。
密閉型のビルドプロセスを使用すると、ツリーの ABI の記述の整合性も保たれます。これは Google が生成したもの（android13-5.15 の abi_gki_aarch64.xml など）でも、ベンダー モジュールなどのローカルツリーで生成されたものでも同様です。カーネル モジュール インターフェース（KMI）の ABI の記述を作成して比較するためのツールも、マニフェストで説明されているリポジトリの一部として提供されています。
GKI カーネルのビルドに使用するツールチェーンは、ベンダー モジュールをビルドするために使用するツールチェーンと完全互換である必要があります。Android 10 以降、すべての Android カーネルは LLVM ツールチェーンでビルドする必要があります。GKI では、プロダクト カーネルとベンダー モジュールをビルドするために使用する LLVM ツールチェーンで、AOSP の LLVM ツールチェーンと同じ ABI を生成する必要があります。また、パートナーは KMI が GKI カーネルと互換性があることを確認する必要があります。最適な互換性を実現するために、提供されているビルドツールを使用することを強くおすすめします。
次のステップ
密閉型のビルドプロセスと LLVM ツールチェーンを使用してカーネルをビルドする手順については、カーネルのビルドをご覧ください。
ABI をモニタリングし、問題を修正する方法については、Android カーネル ABI のモニタリングをご覧ください。