Partecipa al nostro sondaggio sull'usabilità per migliorare questo sito.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Creazione di kernel

Questa pagina descrive in dettaglio il processo di creazione di kernel personalizzati per i dispositivi Android. Le seguenti istruzioni guidano l'utente attraverso il processo di selezione delle sorgenti giuste, compilazione del kernel e incorporamento dei risultati in un'immagine di sistema costruita dal progetto Android Open Source (AOSP).

I sorgenti del kernel più recenti possono essere acquisiti utilizzando Repo ed essere build/build.sh senza ulteriore configurazione eseguendo build/build.sh dalla radice del checkout del codice sorgente.

Per kernel più vecchi o kernel non elencati di seguito, fare riferimento alle istruzioni su come creare kernel legacy .

Download di sorgenti e strumenti di compilazione

Per i kernel recenti, usa il repo per scaricare i sorgenti, la toolchain e gli script di compilazione. Alcuni kernel (ad esempio, i kernel Pixel 3) richiedono fonti da più repository git, mentre altri (ad esempio, i kernel comuni) richiedono solo una singola fonte. L'utilizzo dell'approccio repo garantisce una corretta configurazione della directory di origine.

Scarica i sorgenti per il ramo appropriato:

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

La tabella seguente elenca i nomi BRANCH per i kernel disponibili tramite questo metodo.

Dispositivo Percorso binario nell'albero AOSP Repo branch
Pixel 5 (redfin)
Pixel 4a (5G) (rovo)
dispositivo / google / redbull-kernel android-msm-redbull-4.19-android11-qpr2
Pixel 4a (pesce luna) dispositivo / google / sunfish-kernel android-msm-sunfish-4.14-android11-qpr2
Pixel 4 (fiamma)
Pixel 4 XL (corallo)
dispositivo / google / coral-kernel android-msm-coral-4.14-android11-qpr2
Pixel 3a (sargo)
Pixel 3a XL (bonito)
dispositivo / google / bonito-kernel android-msm-bonito-4.9-android11-qpr2
Pixel 3 (blueline)
Pixel 3 XL (tratteggio incrociato)
dispositivo / google / crosshatch-kernel android-msm-crosshatch-4.9-android11-qpr2
Pixel 2 (walleye)
Pixel 2 XL (taimen)
dispositivo / google / wahoo-kernel android-msm-wahoo-4.4-android10-qpr3
Pixel (pesce vela)
Pixel XL (marlin)
dispositivo / google / marlin-kernel android-msm-marlin-3.18-pie-qpr2
Hikey960 dispositivo / linaro / hikey-kernel hikey-linaro-android-4.14
hikey-linaro-android-4.19
common-android12-5.4
Beagle x15 dispositivo / ti / beagle_x15-kernel omap-beagle-x15-android-4.14
omap-beagle-x15-android-4.19
Kernel comune Android N / A common-android-4.4
common-android-4.9
common-android-4.14
common-android-4.19
common-android-4.19-stabile
common-android11-5.4
common-android12-5.4
common-android12-5.10
common-android-mainline

Compilare il kernel

Quindi compila il kernel con:

build/build.sh

Il file binario del kernel, i moduli e l'immagine corrispondente si trovano nella directory out/ BRANCH /dist .

Costruire i moduli GKI

Android 11 ha introdotto GKI , che separa il kernel in un'immagine del kernel gestita da Google e moduli gestiti dal fornitore, che sono costruiti separatamente.

Un esempio di configurazione dell'immagine del kernel:

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

Un esempio di configurazione del modulo (Cuttlefish ed Emulator):

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

Esecuzione del kernel

Esistono diversi modi per eseguire un kernel personalizzato. I seguenti sono modi noti adatti a vari scenari di sviluppo.

Incorporamento nella build dell'immagine Android

Copiare Image.lz4-dtb nella rispettiva posizione binaria del kernel all'interno dell'albero AOSP e ricostruire l'immagine di avvio.

In alternativa, definire la TARGET_PREBUILT_KERNEL variabile durante l'utilizzo make bootimage (o qualsiasi altra make riga di comando che crea un'immagine di avvio). Questa variabile è supportata da tutti i dispositivi poiché è configurata tramite device/common/populate-new-device.sh . Per esempio:

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Flash e avvio dei kernel con fastboot

I dispositivi più recenti hanno un'estensione del bootloader per semplificare il processo di generazione e avvio di un'immagine di avvio.

Per avviare il kernel senza eseguire il flashing:

adb reboot bootloader
fastboot boot Image.lz4-dtb

Usando questo metodo, il kernel non è effettivamente aggiornato e non persisterà durante un riavvio.

Personalizzare la build del kernel

Il processo di creazione e il risultato possono essere influenzati dalle variabili di ambiente. La maggior parte di essi sono opzionali e ogni ramo del kernel dovrebbe avere una corretta configurazione predefinita. Quelli utilizzati più di frequente sono elencati qui. Per un elenco completo (e aggiornato), fare riferimento a build/build.sh .

Variabile d'ambiente Descrizione Esempio
BUILD_CONFIG Compila il file di configurazione da cui inizializzare l'ambiente di compilazione. La posizione deve essere definita rispetto alla directory root del repository. Il valore predefinito è build.config .
Obbligatorio per i kernel comuni.
BUILD_CONFIG=common/build.config.gki.aarch64
OUT_DIR Directory di output di base per la build del kernel. OUT_DIR=/path/to/my/out
DIST_DIR Directory di output di base per la distribuzione del kernel. OUT_DIR=/path/to/my/dist
CC Sostituisci il compilatore da utilizzare. Torna al compilatore predefinito definito da build.config . CC=clang
SKIP_MRPROPER Salta make mrproper SKIP_MRPROPER=1
SKIP_DEFCONFIG Salta make defconfig SKIP_DEFCONFIG=1

Configurazione del kernel personalizzata per build locali

Se è necessario cambiare regolarmente un'opzione di configurazione del kernel, ad esempio, quando si lavora su una funzionalità, o se è necessario impostare un'opzione per scopi di sviluppo, è possibile ottenere tale flessibilità mantenendo una modifica locale o una copia della configurazione della build.

Impostare la variabile POST_DEFCONFIG_CMDS su un'istruzione che viene valutata subito dopo il normale passaggio di make defconfig . Poiché i file build.config vengono inseriti nell'ambiente di compilazione, le funzioni definite in build.config possono essere chiamate come parte dei comandi post-defconfig.

Un esempio comune è la disabilitazione dell'ottimizzazione del tempo di collegamento (LTO) per i kernel crosshatch durante lo sviluppo. Sebbene LTO sia vantaggioso per i kernel rilasciati, il sovraccarico al momento della compilazione può essere significativo. Il seguente frammento aggiunto al build.config locale disabilita LTO in modo persistente quando si utilizza 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)
}

Identificazione delle versioni del kernel

Esistono due modi per identificare la versione corretta da creare.

Versione del kernel dall'albero AOSP

L'albero AOSP contiene versioni del kernel precostruite. La maggior parte delle volte il log git rivela la versione corretta come parte del messaggio di commit:

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

Versione del kernel dall'immagine di sistema

Per determinare la versione del kernel utilizzata in un'immagine di sistema, eseguire il seguente comando sul file del kernel:

file kernel

Per i file Image.lz4-dtb , esegui:

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

Creazione di un'immagine di avvio

È possibile creare un'immagine di avvio utilizzando l'ambiente di compilazione del kernel. Per fare ciò è necessario un file binario ramdisk, che è possibile ottenere scaricando un'immagine di avvio GKI e decomprimendola. Qualsiasi immagine di avvio GKI dalla versione Android associata funzionerà.

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

La cartella di destinazione è la directory di primo livello dell'albero del kernel (la directory di lavoro corrente).

Se stai sviluppando con AOSP master, puoi invece scaricare l'artefatto di build ramdisk-recovery.img da una build aosp_arm64 su ci.android.com e usarlo come binario ramdisk.

Quando hai un binario ramdisk e lo hai copiato in gki-ramdisk.lz4 nella directory principale della build del kernel, puoi generare un'immagine di avvio eseguendo:

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

Se stai lavorando con un'architettura basata su x86, sostituisci Image con bzImage e aarch64 con 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

Quel file si trova nella directory artifact $KERNEL_ROOT/out/$KERNEL_VERSION/dist .

L'immagine di avvio si trova in out/<kernel branch>/dist/boot.img .