このページでは、Android デバイス用のカスタムカーネルを構築するプロセスについて詳しく説明します。これらの手順では、適切なソースを選択し、カーネルを構築し、その結果を Android オープン ソース プロジェクト (AOSP) から構築されたシステム イメージに埋め込むプロセスについて説明します。
Repoを使用して、より新しいカーネル ソースを取得できます。ソース チェックアウトのルートからbuild/build.shを実行することにより、それ以上の構成を行わずにそれらをビルドします。
ソースとビルド ツールのダウンロード
最近のカーネルの場合、 repoを使用してソース、ツールチェーン、およびビルド スクリプトをダウンロードします。一部のカーネル (たとえば、Pixel 3 カーネル) は複数の git リポジトリからのソースを必要としますが、他のカーネル (たとえば、一般的なカーネル) は単一のソースのみを必要とします。 repoアプローチを使用すると、ソース ディレクトリが正しく設定されます。
適切なブランチのソースをダウンロードします。
mkdir android-kernel && cd android-kernel
repo init -u https://android.googlesource.com/kernel/manifest -b BRANCH
repo sync
次の表に、この方法で使用できるカーネルのBRANCH名を示します。
| デバイス | AOSP ツリーのバイナリ パス | レポブランチ |
|---|---|---|
| Pixel 7 (パンサー) Pixel 7 Pro（チーター） | device/google/pantah-kernel | android-gs-pantah-5.10-android13-qpr1 |
| Pixel 6a (アオカケス) | デバイス/グーグル/ブルージェイカーネル | android-gs-bluejay-5.10-android13-qpr1 |
| Pixel 6 (オリオール) Pixel 6 Pro (カラス) | device/google/raviole-kernel | android-gs-raviole-5.10-android13-qpr1 |
| Pixel 5a（ゴシキドリ） Pixel 5（レッドフィン） Pixel 4a (5G) (ブランブル) | デバイス/グーグル/レッドブル-カーネル | android-msm-redbull-4.19-android13-qpr1 |
| Pixel 4a（マンボウ） | device/google/マンボウ-カーネル | android-msm-sunfish-4.14-android13-qpr1 |
| Pixel 4（炎） Pixel 4 XL（コーラル） | device/google/coral-kernel | android-msm-coral-4.14-android13 |
| Pixel 3a (サルゴ) Pixel 3a XL（カツオ） | device/google/bonito-kernel | android-msm-bonito-4.9-android12L |
| Pixel 3（ブルーライン） Pixel 3 XL（クロスハッチ） | device/google/crosshatch-kernel | android-msm-crosshatch-4.9-android12 |
| Pixel 2（スケトウダラ） Pixel 2 XL（タイメン） | device/google/wahoo-kernel | android-msm-wahoo-4.4-android10-qpr3 |
| ピクセル (バショウカジキ) Pixel XL (マーリン) | device/google/marlin-kernel | アンドロイド-msm-マーリン-3.18-パイ-qpr2 |
| Hikey960 | デバイス/linaro/hikey-カーネル | ハイキー-リナロ-アンドロイド-4.14 ハイキー-リナロ-アンドロイド-4.19 common-android12-5.4 common-android13-5.10 |
| ビーグル×15 | デバイス/ti/beagle_x15-kernel | omap-beagle-x15-android-4.14 omap-beagle-x15-android-4.19 |
| Android 共通カーネル | なし | 一般的なアンドロイド 4.4 一般的なアンドロイド 4.9 一般的なアンドロイド 4.14 一般的なアンドロイド 4.19 common-android-4.19-stable common-android11-5.4 common-android12-5.4 common-android12-5.10 common-android13-5.10 common-android13-5.15 common-android14-5.15 common-android14-6.1 一般的な Android メインライン |
カーネルの構築
次に、これを使用してカーネルをビルドします。
build/build.sh
カーネル バイナリ、モジュール、および対応するイメージは、 out/ BRANCH /distディレクトリにあります。
Bazel (Kleaf) で構築
Android 13 では、 build/build.shを置き換えて、 Bazelを使用したビルド カーネルが導入されました。
aarch64 アーキテクチャ用の GKI カーネルをビルドするには、Android 13 以前の Android Common Kernel ブランチをチェックアウトしてから、次のコマンドを実行します。
tools/bazel build //common:kernel_aarch64_dist
ディストリビューションを作成するには、次を実行します。
tools/bazel run //common:kernel_aarch64_dist -- --dist_dir=$DIST_DIR
その後、カーネル バイナリ、モジュール、および対応するイメージが$DIST_DIRディレクトリに配置されます。 --dist_dirが指定されていない場合は、アーティファクトの場所についてコマンドの出力を参照してください。詳細については、 AOSP のドキュメントを参照してください。
仮想デバイスのベンダー モジュールの構築
Android 11 ではGKIが導入されました。これにより、カーネルが Google が管理するカーネル イメージとベンダーが管理するモジュールに分離され、これらは個別にビルドされます。
この例は、カーネル イメージの構成を示しています。
BUILD_CONFIG=common/build.config.gki.x86_64 build/build.sh
この例は、モジュール構成 (Cuttlefish およびエミュレーター) を示しています。
BUILD_CONFIG=common-modules/virtual-device/build.config.cuttlefish.x86_64 build/build.sh
Android 12 では、Cuttlefish と Goldfish が収束するため、同じカーネルvirtual_deviceを共有します。そのカーネルのモジュールをビルドするには、次のビルド構成を使用します。
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.x86_64 build/build.sh
Android 13 では、 build.shを置き換えて、 Bazel (Kleaf) によるビルド カーネルが導入されました。
virtual_deviceのモジュールをビルドするには、次を実行します。
tools/bazel build //common-modules/virtual-device:virtual_device_x86_64_dist
ディストリビューションを作成するには、次を実行します。
tools/bazel run //common-modules/virtual-device:virtual_device_x86_64_dist -- --dist_dir=$DIST_DIR
Bazel を使用した Android カーネルの構築の詳細については、「. Kleaf - Bazel を使用した Android カーネルの構築。
個々のアーキテクチャの Kleaf サポートの詳細については、デバイスとカーネルの Kleaf サポート を参照してください。
デバイスとカーネルの Kleaf サポート
次の表に、個々のデバイス カーネルに対する Kleaf のサポートを示します。一覧にないデバイスについては、デバイスの製造元にお問い合わせください。
| デバイス | レポブランチ | クリーフサポート | build/build.shサポート |
|---|---|---|---|
| Android 共通カーネル db845c 仮想デバイス (x86_64、arm64) 仮想デバイス (i686、アーム) Rockpi4 | 一般的なアンドロイド 4.4 一般的なアンドロイド 4.9 一般的なアンドロイド 4.14 一般的なアンドロイド 4.19 common-android-4.19-stable common-android11-5.4 common-android12-5.4 common-android12-5.10 | ❌ | ✅ |
| Android 共通カーネル | common-android13-5.10 common-android13-5.15 | ✅ | ✅（公式） 1 |
| Android 共通カーネル | common-android14-5.15 common-android14-6.1 一般的な Android メインライン | ✅ | ❌ |
| db845c | common-android13-5.10 | ❌ | ✅ |
| db845c | common-android13-5.15 | ✅ | ✅（公式） 1 |
| db845c | common-android14-5.15 common-android14-6.1 一般的な Android メインライン | ✅ | ❌ |
| 仮想デバイス (x86_64、arm64) | common-android13-5.10 common-android13-5.15 | ✅（公式） 1 | ⚠️ (未整備) 2 |
| 仮想デバイス (x86_64、arm64) | common-android14-5.15 common-android14-6.1 一般的な Android メインライン | ✅ | ❌ |
| 仮想デバイス (i686、アーム) | common-android13-5.10 common-android13-5.15 | ❌ | ✅ |
| 仮想デバイス (i686、アーム) | common-android14-5.15 common-android14-6.1 一般的な Android メインライン | ✅ | ❌ |
| Rockpi4 | common-android13-5.10 common-android13-5.15 | ❌ | ✅ |
| Rockpi4 | common-android14-5.15 common-android14-6.1 一般的な Android メインライン | ✅ | ❌ |
| Hikey960 | ハイキー-リナロ-アンドロイド-4.14 ハイキー-リナロ-アンドロイド-4.19 common-android12-5.4 common-android13-5.10 | ❌ | ✅ |
| fips140 モジュール | common-android12-5.10 common-android13-5.10 common-android13-5.15 | ❌ | ✅ |
| fips140 モジュール | common-android14-5.15 | ✅ | ❌ |
1 「公式」とは、これがカーネルを構築する公式の方法であることを意味しますが、別の方法でカーネルを構築することもできます。 2 「保守されていない」とは、この方法でカーネルをビルドする必要があるが、ビルド方法が継続的にテストされていないことを意味します。将来、建設を停止する可能性があります。代わりに「公式」のビルド方法を使用してください。 | |||
カーネルの実行
カスタムビルドのカーネルを実行するには、複数の方法があります。以下は、さまざまな開発シナリオに適した既知の方法です。
Android イメージ ビルドへの埋め込み
Image.lz4-dtbを AOSP ツリー内のそれぞれのカーネル バイナリの場所にコピーし、ブート イメージを再構築します。
または、 make bootimage (またはブート イメージを構築するその他のmakeコマンド ライン) を使用してTARGET_PREBUILT_KERNEL変数を定義します。この変数は、 device/common/populate-new-device.shで設定されているため、すべてのデバイスでサポートされています。例えば：
export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb
fastboot によるカーネルのフラッシュとブート
最近のほとんどのデバイスには、ブート イメージの生成と起動のプロセスを効率化するためのブートローダー拡張機能があります。
フラッシュせずにカーネルを起動するには:
adb reboot bootloaderfastboot boot Image.lz4-dtb
この方法を使用すると、カーネルは実際にはフラッシュされず、再起動しても維持されません。
カーネル ビルドのカスタマイズ
Kleaf ビルドのカーネル ビルドをカスタマイズするには、 Kleaf のドキュメントを参照してください。
build/build.shの場合、ビルド プロセスと結果は環境変数の影響を受ける可能性があります。それらのほとんどはオプションであり、各カーネル ブランチには適切なデフォルト設定が付属している必要があります。最も頻繁に使用されるものをここにリストします。完全な (そして最新の) リストについては、 build/build.shを参照してください。
| 環境変数 | 説明 | 例 |
|---|---|---|
BUILD_CONFIG | ビルド環境を初期化する場所から構成ファイルをビルドします。場所は、Repo ルート ディレクトリに対して相対的に定義する必要があります。デフォルトはbuild.configです。一般的なカーネルでは必須です。 | BUILD_CONFIG=common/build.config.gki.aarch64 |
CC | 使用するコンパイラをオーバーライドします。 build.configで定義されたデフォルトのコンパイラにフォールバックします。 | CC=clang |
DIST_DIR | カーネル ディストリビューションのベース出力ディレクトリ。 | DIST_DIR=/path/to/my/dist |
OUT_DIR | カーネル ビルドのベース出力ディレクトリ。 | OUT_DIR=/path/to/my/out |
SKIP_DEFCONFIG | make defconfigスキップ | SKIP_DEFCONFIG=1 |
SKIP_MRPROPER | make mrproperスキップ | SKIP_MRPROPER=1 |
ローカル ビルド用のカスタム カーネル構成
カーネル構成オプションを定期的に切り替える必要がある場合 (機能の作業中など)、または開発目的でオプションを設定する必要がある場合は、ビルド構成のローカルの変更またはコピーを維持することで、その柔軟性を実現できます。
変数POST_DEFCONFIG_CMDSを、通常のmake defconfigステップが完了した直後に評価されるステートメントに設定します。 build.configファイルがビルド環境に読み込まれるため、 build.configで定義された関数を定義後のコマンドの一部として呼び出すことができます。
一般的な例は、開発中にクロスハッチ カーネルのリンク時間最適化 (LTO) を無効にすることです。 LTO はリリースされたカーネルにとって有益ですが、ビルド時のオーバーヘッドが大きくなる可能性があります。ローカルのbuild.configに追加された次のスニペットは、 build/build.shの使用時に LTO を永続的に無効にします。
POST_DEFCONFIG_CMDS="check_defconfig && update_debug_config"
function update_debug_config() {
${KERNEL_DIR}/scripts/config --file ${OUT_DIR}/.config \
-d LTO \
-d LTO_CLANG \
-d CFI \
-d CFI_PERMISSIVE \
-d CFI_CLANG
(cd ${OUT_DIR} && \
make O=${OUT_DIR} $archsubarch CC=${CC} CROSS_COMPILE=${CROSS_COMPILE} olddefconfig)
}
カーネル バージョンの識別
AOSP ツリーとシステム イメージの 2 つのソースから、ビルドする正しいバージョンを特定できます。
AOSP ツリーのカーネル バージョン
AOSP ツリーには、ビルド済みのカーネル バージョンが含まれています。 git ログは、コミット メッセージの一部として正しいバージョンを明らかにします。
cd $AOSP/device/VENDOR/NAMEgit log --max-count=1
カーネル バージョンが git ログにリストされていない場合は、以下で説明するように、システム イメージから取得します。
システム イメージからのカーネル バージョン
システム イメージで使用されているカーネル バージョンを確認するには、カーネル ファイルに対して次のコマンドを実行します。
file kernel
Image.lz4-dtbファイルの場合、次を実行します。
grep -a 'Linux version' Image.lz4-dtb
ブート イメージの構築
カーネル ビルド環境を使用してブート イメージをビルドすることができます。
init_bootを使用したデバイスのブート イメージの構築
init_bootパーティションを持つデバイスの場合、ブート イメージはカーネルと共に構築されます。 initramfsイメージはブート イメージに組み込まれていません。
たとえば、Kleaf では、次のように GKI ブート イメージをビルドできます。
tools/bazel run //common:kernel_aarch64_dist -- --dist_dir=$DIST_DIR
build/build.shを使用すると、次のように GKI ブート イメージをビルドできます。
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
GKI ブート イメージは$DIST_DIRにあります。
init_bootを使用しないデバイスのブート イメージの構築
init_bootパーティションのないデバイスの場合、RAM ディスク バイナリが必要です。これは、GKI ブート イメージをダウンロードして解凍することで取得できます。関連する Android リリースの GKI ブート イメージはすべて機能します。
tools/mkbootimg/unpack_bootimg.py --boot_img=boot-5.4-gz.img
mv $KERNEL_ROOT/out/ramdisk gki-ramdisk.lz4
ターゲット フォルダーは、カーネル ツリーの最上位ディレクトリ (現在の作業ディレクトリ) です。
AOSP マスターを使用して開発している場合は、代わりにci.android.comの aosp_arm64 ビルドからramdisk-recovery.imgビルド アーティファクトをダウンロードし、それを ramdisk バイナリとして使用できます。
RAM ディスク バイナリがあり、それをカーネル ビルドのルート ディレクトリにあるgki-ramdisk.lz4にコピーしたら、次のコマンドを実行してブート イメージを生成できます。
BUILD_BOOT_IMG=1 SKIP_VENDOR_BOOT=1 KERNEL_BINARY=Image GKI_RAMDISK_PREBUILT_BINARY=gki-ramdisk.lz4 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
x86 ベースのアーキテクチャを使用している場合は、 ImageをbzImageに、 aarch64をx86_64に置き換えます。
BUILD_BOOT_IMG=1 SKIP_VENDOR_BOOT=1 KERNEL_BINARY=bzImage GKI_RAMDISK_PREBUILT_BINARY=gki-ramdisk.lz4 BUILD_CONFIG=common/build.config.gki.x86_64 build/build.sh
そのファイルはアーティファクト ディレクトリ$KERNEL_ROOT/out/$KERNEL_VERSION/distにあります。
ブート イメージはout/<kernel branch>/dist/boot.imgにあります。