Noyaux de construction

Cette page détaille le processus de construction personnalisés noyaux pour les appareils Android. Ces instructions vous guident tout au long du processus de sélection des bonnes sources, de construction du noyau et d'intégration des résultats dans une image système créée à partir du projet Android Open Source (AOSP).

Vous pouvez acquérir plus récentes sources du noyau à l'aide de prise en pension ; les construire sans configuration supplémentaire en exécutant build/build.sh de la racine de votre caisse source.

Pour construire les noyaux plus anciens ou les noyaux ne figure pas sur cette page, reportez - vous aux instructions sur la façon de construire les noyaux existants .

Téléchargement des sources et outils de compilation

Pour les noyaux récents, utilisation repo pour télécharger les sources, l' ensemble des outils et des scripts de compilation. Certains noyaux (par exemple, les noyaux Pixel 3) nécessitent des sources provenant de plusieurs référentiels git, tandis que d'autres (par exemple, les noyaux communs) ne nécessitent qu'une seule source. Utilisation de la repo en repo approche permet une configuration du répertoire source correcte.

Téléchargez les sources de la branche appropriée :

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

Le tableau ci - dessous les BRANCH nom pour les noyaux disponibles par le biais de cette méthode.

Dispositif Chemin binaire dans l'arborescence AOSP Branches de pension
Pixel 5a (barbet) appareil/google/barbet-kernel android-msm-barbet-4.19-android12
Pixel 5 (rouge)
Pixel 4a (5G) (ronce)
appareil/google/redbull-kernel android-msm-redbull-4.19-android12
Pixel 4a (poisson-lune) appareil/google/sunfish-kernel android-msm-sunfish-4.14-android12
Pixel 4 (flamme)
Pixel 4 XL (corail)
appareil/google/coral-kernel android-msm-corail-4.14-android12
Pixel 3a (sargo)
Pixel 3a XL (bonite)
appareil/google/bonito-kernel android-msm-bonito-4.9-android12
Pixel 3 (ligne bleue)
Pixel 3 XL (haché)
appareil/google/crosshatch-kernel android-msm-crosshatch-4.9-android12
Pixel 2 (doré)
Pixel 2 XL (taimen)
appareil/google/wahoo-kernel android-msm-wahoo-4.4-android10-qpr3
Pixel (voilier)
Pixel XL (marlin)
appareil/google/marlin-kernel android-msm-marlin-3.18-pie-qpr2
Hikey960 appareil/linaro/hikey-kernel randonneur-linaro-android-4.14
randonneur-linaro-android-4.19
commun-android12-5.4
Beagle x15 périphérique/ti/beagle_x15-kernel omap-beagle-x15-android-4.14
omap-beagle-x15-android-4.19
Noyau commun Android N / A commun-android-4.4
commun-android-4.9
commun-android-4.14
commun-android-4.19
commun-android-4.19-stable
commun-android11-5.4
commun-android12-5.4
commun-android12-5.10
common-android-mainline

Construire le noyau

Ensuite, construisez le noyau avec ceci :

build/build.sh

Le binaire du noyau, les modules et l' image correspondante sont situés dans la out/ BRANCH /dist répertoire.

Construire les modules GKI

Applications 11 introduit GKI , qui sépare le noyau en une image de noyau entretenues Google et fournisseurs maintenus-modules, qui sont construits séparément.

Cet exemple montre une configuration d'image de noyau :

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

Cet exemple montre une configuration de module (Seiche et émulateur) :

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

Dans Android 12 Seiche et Converge Poisson rouge, ils partagent le même noyau: virtual_device . Pour construire les modules de ce noyau, utilisez cette configuration de construction :

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

Exécuter le noyau

Il existe plusieurs façons d'exécuter un noyau personnalisé. Les méthodes suivantes sont connues et adaptées à divers scénarios de développement.

Intégration dans la construction d'image Android

Copie Image.lz4-dtb à l'emplacement binaire du noyau respectif dans l'arborescence PSBA et reconstruire l'image de démarrage.

En variante, définir la TARGET_PREBUILT_KERNEL variable tout en utilisant make bootimage (ou toute autre make de ligne de commande qui construit une image de démarrage). Cette variable est prise en charge par tous les appareils qu'il est mis en place par l' device/common/populate-new-device.sh . Par exemple:

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Flasher et démarrer les noyaux avec fastboot

Les appareils les plus récents ont une extension de chargeur de démarrage pour rationaliser le processus de génération et de démarrage d'une image de démarrage.

Pour démarrer le noyau sans flasher :

adb reboot bootloader
fastboot boot Image.lz4-dtb

En utilisant cette méthode, le noyau n'est pas réellement flashé et ne persistera pas lors d'un redémarrage.

Personnaliser la construction du noyau

Le processus de génération et le résultat peuvent être influencés par des variables d'environnement. La plupart d'entre eux sont facultatifs et chaque branche du noyau doit être fournie avec une configuration par défaut appropriée. Les plus fréquemment utilisés sont listés ici. Pour une couverture complète (et mise à jour) liste, reportez - vous à la build/build.sh .

Variable d'environnement La description Exemple
BUILD_CONFIG Fichier de configuration de build à partir duquel vous initialisez l'environnement de build. L'emplacement doit être défini par rapport au répertoire racine du Repo. Par défaut build.config .
Obligatoire pour les noyaux communs.
BUILD_CONFIG=common/build.config.gki.aarch64
CC Remplacer le compilateur à utiliser. Retour au chutes compilateur par défaut défini par build.config . CC=clang
DIST_DIR Répertoire de sortie de base pour la distribution du noyau. DIST_DIR=/path/to/my/dist
OUT_DIR Répertoire de sortie de base pour la construction du noyau. OUT_DIR=/path/to/my/out
SKIP_DEFCONFIG Sauter make defconfig SKIP_DEFCONFIG=1
SKIP_MRPROPER Sauter make mrproper SKIP_MRPROPER=1

Configuration de noyau personnalisée pour les versions locales

Si vous devez changer régulièrement d'option de configuration du noyau, par exemple lorsque vous travaillez sur une fonctionnalité, ou si vous avez besoin de définir une option à des fins de développement, vous pouvez obtenir cette flexibilité en maintenant une modification ou une copie locale de la configuration de construction.

Définissez la variable POST_DEFCONFIG_CMDS à une déclaration qui est évaluée juste après l'habituel make defconfig pas est fait. Comme les build.config fichiers sont achetés dans l'environnement de construction, les fonctions définies dans build.config peuvent être appelés dans le cadre des commandes post-defconfig.

Un exemple courant est la désactivation de l'optimisation du temps de liaison (LTO) pour les noyaux de hachures pendant le développement. Alors que LTO est bénéfique pour les noyaux publiés, la surcharge au moment de la construction peut être importante. L'extrait suivant ajouté à la section locale build.config désactive LTO persistante lors de l' utilisation 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)
}

Identification des versions du noyau

Vous pouvez identifier la version correcte à construire à partir de deux sources : l'arborescence AOSP et l'image système.

Version du noyau de l'arborescence AOSP

L'arborescence AOSP contient des versions de noyau préconstruites. Le journal git révèle la version correcte dans le cadre du message de validation :

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

Si la version du noyau n'est pas répertoriée dans le journal git, obtenez-la à partir de l'image système, comme décrit ci-dessous.

Version du noyau à partir de l'image système

Pour déterminer la version du noyau utilisée dans une image système, exécutez la commande suivante sur le fichier du noyau :

file kernel

Pour Image.lz4-dtb fichiers, exécutez:

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

Création d'une image de démarrage

Il est possible de construire une image de démarrage en utilisant l'environnement de construction du noyau. Pour ce faire, vous avez besoin d'un binaire de disque virtuel, que vous pouvez obtenir en téléchargeant une image de démarrage GKI et en la décompressant. Toute image de démarrage GKI de la version Android associée fonctionnera.

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

Le dossier cible est le répertoire de niveau supérieur de l'arborescence du noyau (le répertoire de travail actuel).

Si vous développez avec le maître PSBA, vous pouvez télécharger le lieu ramdisk-recovery.img artefact de construction d'une accumulation de aosp_arm64 sur ci.android.com et l' utiliser comme votre binaire ramdisk.

Lorsque vous avez un binaire ramdisk et ont copié à gki-ramdisk.lz4 dans le répertoire racine du compilation du noyau, vous pouvez générer une image de démarrage en exécutant:

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

Si vous travaillez avec l' architecture x86, remplacez l' Image avec bzImage et aarch64 avec 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

Ce fichier se trouve dans le répertoire d'artefact $KERNEL_ROOT/out/$KERNEL_VERSION/dist .

L'image de démarrage est situé à out/<kernel branch>/dist/boot.img .