Kernel erstellen

Auf dieser Seite wird beschrieben, wie Sie benutzerdefinierte Kernel für Android-Geräte erstellen. In dieser Anleitung wird beschrieben, wie Sie die richtigen Quellen auswählen, den Kernel erstellen und die Ergebnisse in ein System-Image einbetten, das aus dem Android Open Source Project (AOSP) erstellt wurde.

Quellen und Build-Tools herunterladen

Verwenden Sie für aktuelle Kernel repo, um die Quellen, die Toolchain und die Build-Skripts herunterzuladen. Für einige Kernel (z. B. die Pixel 3-Kernel) sind Quellen aus mehreren Git-Repositories erforderlich, während für andere (z. B. die gemeinsamen Kernel) nur eine Quelle erforderlich ist. Wenn Sie den repo-Ansatz verwenden, wird das Quellverzeichnis richtig eingerichtet.

Laden Sie die Quellen für den entsprechenden Branch herunter:

mkdir android-kernel && cd android-kernel
 
repo init -u https://android.googlesource.com/kernel/manifest -b BRANCH
 
repo sync

Eine Liste der Repository-Zweige (BRANCH), die mit dem vorherigen `repo init`-Befehl verwendet werden können, finden Sie unter Kernel-Zweige und ihre Build-Systeme.

Weitere Informationen zum Herunterladen und Kompilieren von Kernels für Pixel-Geräte finden Sie unter Pixel-Kernels erstellen.

Kernel erstellen

Mit Bazel erstellen (Kleaf)

In Android 13 wurde die Möglichkeit eingeführt, Kernel mit Bazel zu erstellen.

Wenn Sie eine Distribution für den GKI-Kernel für die AArch64-Architektur erstellen möchten, prüfen Sie, ob ein Android Common Kernel-Zweig vorhanden ist, der nicht älter als Android 13 ist, und führen Sie dann den folgenden Befehl aus:

tools/bazel run //common:kernel_aarch64_dist [-- --destdir=$DIST_DIR]

Danach befinden sich die Kernel-Binärdatei, die Module und die entsprechenden Images im Verzeichnis $DIST_DIR. Wenn --destdir nicht angegeben ist, finden Sie den Speicherort der Artefakte in der Ausgabe des Befehls. Weitere Informationen finden Sie in der AOSP-Dokumentation.

Mit „build.sh“ erstellen (Legacy)

Für Branches mit Android 12 oder niedriger ODER Branches ohne Kleaf: 

build/build.sh

Die Kernel-Binärdatei, die Module und das entsprechende Image befinden sich im Verzeichnis out/BRANCH/dist.

Anbietermodule für das virtuelle Gerät erstellen

In Android 13 wurde die Entwicklung von Kernels mit Bazel (Kleaf) eingeführt, wodurch build.sh ersetzt wurde.

So erstellen Sie eine Verteilung für die Module von virtual_device:

tools/bazel run //common-modules/virtual-device:virtual_device_x86_64_dist [-- --destdir=$DIST_DIR]

Weitere Informationen zum Erstellen von Android-Kerneln mit Bazel finden Sie unter. Kleaf – Android-Kernel mit Bazel erstellen

Weitere Informationen zur Kleaf-Unterstützung für einzelne Architekturen finden Sie unter Kleaf-Unterstützung für Geräte und Kernel.

Anbietermodule für das virtuelle Gerät mit „build.sh“ erstellen (Legacy)

In Android 12 werden Cuttlefish und Goldfish zusammengeführt, sodass sie denselben Kernel verwenden: virtual_device. Verwenden Sie diese Build-Konfiguration, um die Module des Kernels zu erstellen:

BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.x86_64 build/build.sh

Mit Android 11 wurde GKI eingeführt. Dabei wird der Kernel in ein von Google verwaltetes Kernel-Image und von Anbietern verwaltete Module unterteilt, die separat erstellt werden.

Dieses Beispiel zeigt eine Kernel-Image-Konfiguration:

BUILD_CONFIG=common/build.config.gki.x86_64 build/build.sh

In diesem Beispiel sehen Sie eine Modulkonfiguration (Cuttlefish und Emulator):

BUILD_CONFIG=common-modules/virtual-device/build.config.cuttlefish.x86_64 build/build.sh

Kernel ausführen

Es gibt mehrere Möglichkeiten, einen benutzerdefinierten Kernel auszuführen. Im Folgenden finden Sie bekannte Methoden, die sich für verschiedene Entwicklungsszenarien eignen.

In den Android-Image-Build einbetten

Kopieren Sie Image.lz4-dtb in den entsprechenden Speicherort der Kernel-Binärdatei im AOSP-Baum und erstellen Sie das Boot-Image neu.

Alternativ können Sie die Variable TARGET_PREBUILT_KERNEL definieren, während Sie make bootimage (oder eine andere make-Befehlszeile, mit der ein Boot-Image erstellt wird) verwenden. Diese Variable wird von allen Geräten unterstützt, da sie über device/common/populate-new-device.sh eingerichtet wird. Beispiel:

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Kernel mit Fastboot flashen und starten

Die meisten aktuellen Geräte haben eine Bootloader-Erweiterung, um das Erstellen und Booten eines Boot-Images zu vereinfachen.

So booten Sie den Kernel, ohne ihn zu flashen:

adb reboot bootloader
fastboot boot Image.lz4-dtb

Bei dieser Methode wird der Kernel nicht geflasht und bleibt nach einem Neustart nicht erhalten.

Kernel auf Cuttlefish ausführen

Sie können Kernel in der Architektur Ihrer Wahl auf Cuttlefish-Geräten ausführen.

Wenn Sie ein Cuttlefish-Gerät mit einer bestimmten Gruppe von Kernel-Artefakten starten möchten, führen Sie den Befehl cvd create mit den Ziel-Kernel-Artefakten als Parameter aus. Im folgenden Beispielbefehl werden Kernel-Artefakte für ein arm64-Ziel aus dem Kernel-Manifest common-android14-6.1 verwendet.

cvd create \
    -kernel_path=/$PATH/$TO/common-android14-6.1/out/android14-6.1/dist/Image \
    -initramfs_path=/$PATH/$TO/common-android14-6.1/out/android14-6.1/dist/initramfs.img

Weitere Informationen finden Sie unter Kernel auf Cuttlefish entwickeln.

Kernel-Build anpassen

Informationen zum Anpassen der Kernel-Builds für Kleaf-Builds finden Sie in der Kleaf-Dokumentation.

Kernel-Build mit build.sh anpassen (Legacy)

Bei build/build.sh können der Build-Prozess und das Ergebnis durch Umgebungsvariablen beeinflusst werden. Die meisten sind optional und jeder Kernel-Branch sollte eine geeignete Standardkonfiguration haben. Die am häufigsten verwendeten werden hier aufgeführt. Eine vollständige und aktuelle Liste finden Sie unter build/build.sh.

Umgebungsvariable Beschreibung Beispiel
BUILD_CONFIG Build-Konfigurationsdatei, über die Sie die Build-Umgebung initialisieren. Der Speicherort muss relativ zum Stammverzeichnis des Repositorys definiert werden. Die Standardeinstellung ist build.config.
Für gängige Kernel erforderlich. 		BUILD_CONFIG=common/build.config.gki.aarch64
CC Überschreibt den zu verwendenden Compiler. Greift auf den Standardcompiler zurück, der von build.config definiert wird. CC=clang
DIST_DIR Basisausgabeverzeichnis für die Kernel-Distribution. DIST_DIR=/path/to/my/dist
OUT_DIR Basisausgabeverzeichnis für den Kernel-Build. OUT_DIR=/path/to/my/out
SKIP_DEFCONFIG Überspringen make defconfig SKIP_DEFCONFIG=1
SKIP_MRPROPER Überspringen make mrproper SKIP_MRPROPER=1

Benutzerdefinierte Kernelkonfiguration für lokale Builds

In Android 14 und höher können Sie Defconfig-Fragmente verwenden, um Kernelkonfigurationen anzupassen. Weitere Informationen finden Sie in der Kleaf-Dokumentation zu Defconfig-Fragmenten.

Benutzerdefinierte Kernelkonfiguration für lokale Builds mit Build-Konfigurationen (Legacy)

Bei Android 13 und niedriger gilt Folgendes:

Wenn Sie eine Kernelkonfigurationsoption regelmäßig wechseln müssen, z. B. wenn Sie an einem Feature arbeiten, oder wenn Sie eine Option für Entwicklungszwecke festlegen müssen, können Sie diese Flexibilität erreichen, indem Sie eine lokale Änderung oder Kopie der Build-Konfiguration beibehalten.

Legen Sie die Variable POST_DEFCONFIG_CMDS auf eine Anweisung fest, die direkt nach dem üblichen make defconfig-Schritt ausgewertet wird. Da die build.config-Dateien in die Build-Umgebung eingefügt werden, können Funktionen, die in build.config definiert sind, als Teil der post-defconfig-Befehle aufgerufen werden.

Ein häufiges Beispiel ist das Deaktivieren der Link Time Optimization (LTO) für Crosshatch-Kernel während der Entwicklung. LTO ist zwar für veröffentlichte Kernel von Vorteil, der Aufwand zur Build-Zeit kann jedoch erheblich sein. Das folgende Snippet, das der lokalen build.config hinzugefügt wird, deaktiviert LTO dauerhaft, wenn build/build.sh verwendet wird.

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)
}

Kernel-Versionen ermitteln

Sie können die richtige Version für den Build aus zwei Quellen ermitteln: dem AOSP-Baum und dem System-Image.

Kernel-Version aus dem AOSP-Baum

Der AOSP-Baum enthält vorgefertigte Kernelversionen. Das Git-Log zeigt die richtige Version als Teil der Commit-Nachricht an:

cd $AOSP/device/VENDOR/NAME
git log --max-count=1

Wenn die Kernelversion nicht im Git-Log aufgeführt ist, rufen Sie sie wie unten beschrieben aus dem Systemimage ab.

Kernel-Version aus dem System-Image

Führen Sie den folgenden Befehl für die Kerndatei aus, um die im System-Image verwendete Kernelversion zu ermitteln:

file kernel

Führen Sie für Image.lz4-dtb-Dateien Folgendes aus:

grep -a 'Linux version' Image.lz4-dtb

Boot-Image erstellen

Es ist möglich, ein Boot-Image mit der Kernel-Build-Umgebung zu erstellen.

Boot-Image für Geräte mit init_boot erstellen

Bei Geräten mit der Partition init_boot wird das Boot-Image zusammen mit dem Kernel erstellt. Das initramfs-Bild ist nicht in das Boot-Image eingebettet.

Mit Kleaf können Sie beispielsweise das GKI-Boot-Image mit folgendem Befehl erstellen:

tools/bazel run //common:kernel_aarch64_dist [-- --destdir=$DIST_DIR]

Mit build/build.sh (Legacy) können Sie das GKI-Boot-Image mit folgendem Befehl erstellen:

BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh

Das GKI-Boot-Image befindet sich unter $DIST_DIR.

Boot-Image für Geräte ohne init_boot erstellen (Legacy)

Für Geräte ohne init_boot-Partition benötigen Sie eine Ramdisk-Binärdatei, die Sie erhalten, indem Sie ein GKI-Boot-Image herunterladen und es entpacken. Jedes GKI-Boot-Image aus dem zugehörigen Android-Release funktioniert.

tools/mkbootimg/unpack_bootimg.py --boot_img=boot-5.4-gz.img
mv $KERNEL_ROOT/out/ramdisk gki-ramdisk.lz4

Der Zielordner ist das Stammverzeichnis des Kernel-Baums (das aktuelle Arbeitsverzeichnis).

Wenn Sie mit dem aktuellen AOSP-Release-Branch entwickeln, können Sie stattdessen das Build-Artefakt ramdisk-recovery.img aus einem aosp_arm64-Build auf ci.android.com herunterladen und als Ramdisk-Binärdatei verwenden.

Wenn Sie ein Ramdisk-Binärprogramm haben und es in das Stammverzeichnis des Kernel-Builds in gki-ramdisk.lz4 kopiert haben, können Sie ein Boot-Image generieren, indem Sie Folgendes ausführen:

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

Wenn Sie mit einer x86-basierten Architektur arbeiten, ersetzen Sie Image durch bzImage und aarch64 durch 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

Diese Datei befindet sich im Artefaktverzeichnis $KERNEL_ROOT/out/$KERNEL_VERSION/dist.

Das Boot-Image befindet sich unter out/<kernel branch>/dist/boot.img.