Build-Kernel

Auf dieser Seite wird das Erstellen benutzerdefinierter kernels für Android-Geräte. Diese Anleitung zur Auswahl der richtigen Quellen, Erstellen des Kernels und Einbetten der Ergebnisse in ein System-Image basierend auf dem Android Open Source Project (AOSP).

Neuere Kernel-Quellen erhalten Sie mit Repository: um sie zu erstellen, ohne indem Sie build/build.sh im Stammverzeichnis Ihres Quelle für den Bezahlvorgang.

Quellen und Build-Tools herunterladen

Verwenden Sie für aktuelle Kernel repo. um die Quellen, die Toolchain und die Build-Skripts herunterzuladen. Einige Kernel (z. B. die Pixel 3-Kernel) benötigen Quellen von mehreren Git. und bei anderen (z. B. den allgemeinen Kerneln) nur ein einziges Quelle. Mit dem repo-Ansatz wird eine korrekte Quelle sichergestellt. Verzeichniseinrichtung.

Laden Sie die Quellen für den entsprechenden Zweig 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 den Befehl „repo init“, siehe Kernel-Zweige und zugehörige Build-Systeme

Weitere Informationen zum Herunterladen und Kompilieren von Kerneln für Pixel finden Sie unter <ph type="x-smartling-placeholder"></ph> Pixel-Kernel erstellen

Kernel erstellen

Mit Bazel (Kleaf) erstellen

Mit Android 13 wurden Kernel mit Bazel:

Informationen zum Erstellen des GKI-Kernels für die aarch64-Architektur finden Sie in Android Common Kernel-Zweig nicht älter als Android 13 und und führen Sie dann den folgenden Befehl aus:

tools/bazel build //common:kernel_aarch64_dist

Führen Sie folgenden Befehl aus, um eine Verteilung zu erstellen:

tools/bazel run //common:kernel_aarch64_dist -- --dist_dir=$DIST_DIR

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

Build mit build.sh (Legacy)

Für Filialen ab Android 12 ODER Zweige ohne Kleaf:

build/build.sh

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

Anbietermodule für das virtuelle Gerät erstellen

Mit Android 13 wurden Kernel mit Bazel (Kleaf) und ersetzt build.sh.

Führen Sie folgenden Befehl aus, um die Module von virtual_device zu erstellen:

tools/bazel build //common-modules/virtual-device:virtual_device_x86_64_dist

Führen Sie folgenden Befehl aus, um eine Verteilung zu erstellen:

tools/bazel run //common-modules/virtual-device:virtual_device_x86_64_dist -- --dist_dir=$DIST_DIR

Weitere Informationen zum Erstellen von Android-Kerneln mit Bazel finden Sie unter. Kleaf – Building Android Kernels with Base

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 (Legacy) erstellen

In Android 12 vereinen sich Tintenfisch und Goldfische. denselben Kernel: virtual_device. Verwende diesen Build, um die Module dieses Kernels zu erstellen Konfiguration:

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

Einführung von Android 11 Google Maps Platform der den Kernel in ein von Google verwaltetes Kernel-Image und von Anbietern verwaltete Module unterteilt. die separat erstellt werden.

Dieses Beispiel zeigt die Konfiguration eines Kernel-Images:

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

Das folgende Beispiel zeigt 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 für verschiedene Entwicklungsszenarien geeignet sind.

In den Android-Image-Build einbetten

Kopieren Sie Image.lz4-dtb in den jeweiligen binären Kernel-Speicherort im AOSP-Baum und erstellen Sie das Boot-Image neu.

Alternativ können Sie den TARGET_PREBUILT_KERNEL definieren Variable bei Verwendung von make bootimage (oder einer anderen make-Befehlszeile, die ein Boot-Image erstellt). Diese Variable ist wird von allen Geräten unterstützt, da die Einrichtung über device/common/populate-new-device.sh Beispiel:

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Flash- und Boot-Kernel mit Fastboot

Die meisten Geräte verfügen über eine Bootloader-Erweiterung, das Generieren und Starten eines Boot-Images.

So starten Sie den Kernel ohne Flashing:

adb reboot bootloader
fastboot boot Image.lz4-dtb

Bei dieser Methode ist der Kernel nicht tatsächlich geflasht und bleibt nicht erhalten. während eines Neustarts.

Kernel auf Sepia ausführen

Sie können Kernel in der Architektur Ihrer Wahl auf Tintenfisch-Geräte.

Um ein Sepia-Gerät mit einem bestimmten Kernel-Satz zu starten, Artefakte: Führen Sie den Befehl cvd start mit den Ziel-Kernel-Artefakten als Parameter. Im folgenden Beispielbefehl werden Kernel-Artefakte für ein arm64-Ziel vom Kernel-Manifest common-android14-6.1.

cvd start \
    -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 Entwickeln Sie Kernel auf Cuttlefish.

Kernel-Build anpassen

Informationen zum Anpassen der Kernel-Builds für Kleaf-Builds findest du unter Kleaf-Dokumentation

Kernel-Build mit build.sh (Legacy) anpassen

Bei build/build.sh können der Build-Prozess und das Ergebnis beeinflusst werden nach Umgebungsvariablen. Die meisten sind optional und jeder Kernel-Zweig sollte eine passende Standardkonfiguration. Hier sind die am häufigsten genutzten. Für eine vollständige (und aktuelle) Liste finden Sie unter build/build.sh.

Umgebungsvariable	Beschreibung	Beispiel
BUILD_CONFIG	Erstellen Sie die Konfigurationsdatei dort, wo Sie die Build-Umgebung initialisieren. Der Speicherort muss relativ zum Repository-Stamm definiert werden -Verzeichnis. Die Standardeinstellung ist build.config. Obligatorisch für gängige Kernels.	BUILD_CONFIG=common/build.config.gki.aarch64
CC	Zu verwendender Compiler überschreiben. Standardeinstellung wird wiederhergestellt Compiler, der durch build.config definiert ist.	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	make defconfig überspringen	SKIP_DEFCONFIG=1
SKIP_MRPROPER	make mrproper überspringen	SKIP_MRPROPER=1

Benutzerdefinierte Kernel-Konfiguration für lokale Builds

Ab Android 14 können Sie defconfig-Fragmente verwenden um Kernel-Konfigurationen anzupassen. Siehe Kleaf-Dokumentation zu defconfig-Fragmenten

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

Für Android 13 und niedriger gilt Folgendes.

Wenn Sie eine Kernel-Konfigurationsoption regelmäßig wechseln müssen, z. B. wenn Sie an einer Funktion arbeiten oder wenn Sie eine Option für die Entwicklung können Sie diese Flexibilität erreichen, indem Sie Änderung oder Kopie der Build-Konfiguration.

Setzen Sie die Variable POST_DEFCONFIG_CMDS auf eine Anweisung, die direkt nach dem üblichen make defconfig-Schritt ausgewertet, fertig. Da die build.config-Dateien in den Build bezogen werden können die in build.config definierten Funktionen aufgerufen werden als Teil der post-defconfig-Befehle.

Ein gängiges Beispiel ist das Deaktivieren der Link Time-Optimierung (LTO) für Kreuzschraffuren während der Entwicklung. LTO ist zwar nützlich für freigegebene Kernel, kann der Aufwand zur Build-Zeit beträchtlich sein. Das folgende Snippet wurde hinzugefügt: zur lokalen build.config deaktiviert LTO dauerhaft, wenn mit build/build.sh.

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 identifizieren

Sie können die richtige Version aus zwei Quellen ermitteln: der AOSP-Baumstruktur. und das System-Image.

Kernel-Version aus AOSP-Baum

Die AOSP-Baumstruktur enthält vordefinierte Kernel-Versionen. Git Log zeigt die korrekte Version als Teil der Commit-Nachricht an:

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

Wenn die Kernel-Version nicht im Git-Log aufgeführt ist, rufen Sie sie vom System ab. wie unten beschrieben.

Kernel-Version aus System-Image

Führen Sie den folgenden Befehl aus, um die in einem System-Image verwendete Kernel-Version zu ermitteln: für die Kernel-Datei:

file kernel

Führen Sie für Image.lz4-dtb-Dateien folgenden Befehl 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

Für Geräte mit Partition init_boot wird das Boot-Image mit dem Kernel erstellt. Das Bild initramfs ist nicht eingebettet im Boot-Image befinden.

Mit Kleaf können Sie das GKI-Boot-Image beispielsweise so erstellen:

tools/bazel run //common:kernel_aarch64_dist -- --dist_dir=$DIST_DIR

Mit build/build.sh (alte Version) können Sie das GKI-Boot-Image so erstellen:

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

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

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

Für Geräte ohne Partition init_boot benötigen Sie ein Ramdisk-Binärprogramm, das Sie erhalten, indem Sie GKI-Boot-Image herunterladen und auspacken. Jedes GKI-Boot-Image des verknüpften 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 Verzeichnis der obersten Ebene des Kernel-Baums (der aktuelle Arbeitsverzeichnis).

Wenn Sie mit AOSP Main entwickeln, können Sie stattdessen das ramdisk-recovery.img Build-Artefakt von einem Build auf „aosp_arm64“ ci.android.com ein und verwende diese Datei als Ramdisk-Binärprogramm.

Wenn Sie eine Ramdisk-Binärdatei haben und diese nach gki-ramdisk.lz4 im Stammverzeichnis kopiert haben des Kernel-Builds enthält, können Sie mit dem folgenden Befehl ein Boot-Image generieren:

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 mit bzImage und aarch64 mit 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 Verzeichnis „Artefakte“ $KERNEL_ROOT/out/$KERNEL_VERSION/dist

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