Gebäudekerne

Diese Seite enthält Details zum Prozess Brauch Aufbau Kernel für Android - Geräte. Diese Anweisungen führen Sie durch den Prozess der Auswahl der richtigen Quellen, der Erstellung des Kernels und der Einbettung der Ergebnisse in ein Systemabbild, das aus dem Android Open Source Project (AOSP) erstellt wurde.

Sie können mit neueren Kernel - Quellen erwerben Repo ; sie ohne weitere Konfiguration aufbauen , indem Sie build/build.sh von der Wurzel Ihrer Quelle der Kasse.

Um ältere Kernel zu bauen oder Kerne nicht auf dieser Seite aufgeführt sind , beziehen sich auf die Anweisungen, wie zu bauen Legacy - Kernel .

Herunterladen von Quellen und Build-Tools

Für die letzten Kernel, Verwendung repo die Quellen herunterladen, Toolchain und Build - Skripte. Einige Kernel (z. B. die Pixel-3-Kernel) benötigen Quellen aus mehreren Git-Repositorys, während andere (z. B. die üblichen Kernel) nur eine einzige Quelle benötigen. Die Verwendung von repo - Ansatz gewährleistet eine korrekte Quellverzeichnis Setup.

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

Die folgende Tabelle listet die BRANCH - Namen für Kernel durch diese Methode zur Verfügung.

Gerät Binärpfad im AOSP-Baum Repo-Filialen
Pixel 5a (Barbet) device/google/barbet-kernel android-msm-barbet-4.19-android11-d2
Pixel 5 (Rotflossen)
Pixel 4a (5G) (Gestrüpp)
device/google/redbull-kernel android-msm-redbull-4.19-android11-qpr3
Pixel 4a (Sonnenfisch) device/google/sunfish-kernel android-msm-sunfish-4.14-android11-qpr3
Pixel 4 (Flamme)
Pixel 4 XL (Koralle)
device/google/coral-kernel android-msm-coral-4.14-android11-qpr3
Pixel 3a (Sargo)
Pixel 3a XL (bonito)
device/google/bonito-kernel android-msm-bonito-4.9-android11-qpr3
Pixel 3 (blaue Linie)
Pixel 3 XL (Schraffur)
device/google/crosshatch-kernel android-msm-crosshatch-4.9-android11-qpr3
Pixel 2 (Zauge)
Pixel 2 XL (Taimen)
device/google/wahoo-kernel android-msm-wahoo-4.4-android10-qpr3
Pixel (Segelfisch)
Pixel XL (Marlin)
device/google/marlin-kernel android-msm-marlin-3.18-pie-qpr2
Hikey960 Gerät/Linaro/Hikey-Kernel Hikey-Linaro-Android-4.14
Hikey-Linaro-Android-4.19
common-android12-5.4
Beagle x15 device/ti/beagle_x15-kernel omap-beagle-x15-android-4.14
omap-beagle-x15-android-4.19
Gemeinsamer Android-Kernel N / A Common-Android-4.4
Common-Android-4.9
Common-Android-4.14
Common-Android-4.19
common-android-4.19-stabil
common-android11-5.4
common-android12-5.4
common-android12-5.10
common-android-mainline

Kernel bauen

Dann baue den Kernel damit:

build/build.sh

Die Kernelbinärdatei, Module und entsprechende Bild in der ich out/ BRANCH /dist - Verzeichnis.

Aufbau der GKI-Module

Android 11 eingeführt GKI , die den Kernel in ein Google-beibehalten Kernel - Image und hersteller gehalten Module trennt, die separat gebaut werden.

Dieses Beispiel zeigt eine Kernel-Image-Konfiguration:

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

Dieses Beispiel zeigt eine Modulkonfiguration (Cuttlefish und Emulator):

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

Ausführen des Kernels

Es gibt mehrere Möglichkeiten, einen benutzerdefinierten Kernel auszuführen. Die folgenden sind bekannte Wege, die für verschiedene Entwicklungsszenarien geeignet sind.

Einbetten in den Android-Image-Build

Kopieren Image.lz4-dtb an die jeweiligen Kernelbinärdatei Stelle innerhalb des AOSP Baumes und den Wiederaufbau das Boot - Image.

Alternativ definieren die TARGET_PREBUILT_KERNEL Variable während der Verwendung make bootimage (oder jede andere make Befehlszeile , die ein Boot - Image aufbaut). Diese Variable wird von allen Geräten unterstützt , wie es über eingerichtet ist device/common/populate-new-device.sh . Zum Beispiel:

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Flashen und Booten von Kerneln mit Fastboot

Die meisten neueren Geräte verfügen über eine Bootloader-Erweiterung, um den Prozess des Generierens und Bootens eines Boot-Images zu optimieren.

So booten Sie den Kernel ohne zu flashen:

adb reboot bootloader
fastboot boot Image.lz4-dtb

Bei dieser Methode wird der Kernel nicht wirklich geflasht und bleibt auch nach einem Neustart nicht bestehen.

Anpassen des Kernel-Builds

Der Buildprozess und das Ergebnis können durch Umgebungsvariablen beeinflusst werden. Die meisten von ihnen sind optional und jeder Kernel-Zweig sollte mit einer geeigneten Standardkonfiguration geliefert werden. Die am häufigsten verwendeten sind hier aufgelistet. Für eine komplette (und up-to-date) Liste finden Sie unter build/build.sh .

Umgebungsvariable Beschreibung Beispiel
BUILD_CONFIG Build-Konfigurationsdatei, von der aus Sie die Build-Umgebung initialisieren. Der Speicherort muss relativ zum Stammverzeichnis des Repo definiert werden. Defaults build.config .
Obligatorisch für gängige Kernel.
BUILD_CONFIG=common/build.config.gki.aarch64
CC Überschreiben Sie den zu verwendenden Compiler. Falls Zurück zu den Standard - Compiler durch definiert build.config . CC=clang
DIST_DIR Basis-Ausgabeverzeichnis 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 Kernel-Konfiguration für lokale Builds

Wenn Sie regelmäßig eine Kernel-Konfigurationsoption wechseln müssen, zum Beispiel wenn Sie an einem Feature arbeiten, oder wenn eine Option für Entwicklungszwecke gesetzt werden muss, können Sie diese Flexibilität erreichen, indem Sie eine lokale Änderung oder Kopie der Build-Konfiguration beibehalten.

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

Ein gängiges Beispiel ist das Deaktivieren der Link Time Optimization (LTO) für Crosshatch-Kernel während der Entwicklung. Während LTO für veröffentlichte Kernel von Vorteil ist, kann der Overhead zur Build-Zeit erheblich sein. Der folgende Ausschnitt zum lokalen hinzugefügt build.config sperrt dauerhaft LTO bei Verwendung 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)
}

Identifizieren von Kernel-Versionen

Sie können die richtige Version zum Erstellen aus zwei Quellen ermitteln: dem AOSP-Baum und dem Systemabbild.

Kernel-Version vom AOSP-Baum

Der AOSP-Baum enthält vorgefertigte Kernel-Versionen. Das 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 wie unten beschrieben aus dem System-Image ab.

Kernel-Version vom System-Image

Um die in einem Systemabbild verwendete Kernel-Version zu ermitteln, führen Sie den folgenden Befehl für die Kernel-Datei aus:

file kernel

Für Image.lz4-dtb Dateien ausführen:

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

Erstellen eines Boot-Images

Es ist möglich, ein Boot-Image mit der Kernel-Build-Umgebung zu erstellen. Dazu benötigen Sie eine Ramdisk-Binärdatei, die Sie erhalten, indem Sie ein GKI-Boot-Image herunterladen und entpacken. Jedes GKI-Boot-Image der zugehörigen Android-Version funktioniert.

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

Der Zielordner ist das oberste Verzeichnis des Kernelbaums (das aktuelle Arbeitsverzeichnis).

Wenn Sie mit AOSP Master entwickelst, können Sie stattdessen laden Sie die ramdisk-recovery.img - ramdisk-recovery.img Build Artefakt aus einem aosp_arm64 bauen auf ci.android.com und verwenden , die als RAM - Disk binär.

Wenn Sie eine RAM - Disk binäre haben und haben es kopiert gki-ramdisk.lz4 im Stammverzeichnis des Kernels zu bauen, können Sie ein Boot - Image durch Ausführen erzeugen:

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 die Arbeit mit x86-basierten Architektur, ersetzt 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 wird in dem Artefakt Verzeichnis $KERNEL_ROOT/out/$KERNEL_VERSION/dist .

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