Cette page a été traduite par l'API Cloud Translation.

Créer des noyaux

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

Vous pouvez acquérir des sources de noyau plus récentes Repo (Dépôt) les construire sans avoir configuration en exécutant build/build.sh à partir de la racine le processus de paiement à la source.

Remarque:La racine de l'extraction de la source du noyau contient build/build.sh L'arborescence Android ne contient qu'un noyau prédéfini binaires. Les arborescences de noyau contiennent les sources du noyau et tous les outils pour créer les noyaux, y compris ce script.

Télécharger des sources et créer des outils

Pour les noyaux récents, utilisez repo. pour télécharger les sources et la chaîne d'outils, et créer des scripts. Certains noyaux (par exemple, ceux du Pixel 3) nécessitent des sources provenant de plusieurs tandis que d'autres (noyaux courants, par exemple) source. L'utilisation de l'approche repo garantit une source correcte la configuration du répertoire.

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

Pour obtenir la liste des branches de dépôt (BRANCH) pouvant être utilisées avec la "repo init", consultez Branches de noyau et systèmes de compilation associés.

Pour savoir comment télécharger et compiler des noyaux pour les appareils Pixel, consultez <ph type="x-smartling-placeholder"></ph> Building Pixel Kernels (Noyaux de construction de pixels).

Remarque: Vous pouvez basculer d'une branche à l'autre à partir d'un même processus de paiement du dépôt. La les fichiers manifestes courants du noyau (et la plupart des autres) définissent le dépôt Git du noyau d'être entièrement cloné (et non superficielle), ce qui permet de passer rapidement de l'une à l'autre. Le passage à une autre branche est semblable à l'initialisation d'une branche. la Le paramètre -u est facultatif. Par exemple, pour passer à common-android-mainline à partir du règlement de votre dépôt existant, exécution:
$ repo init -b common-android-mainline && repo sync

Créer le noyau

Compiler avec Bazel (Kleaf)

Android 13 a introduit la création de noyaux avec Bazel

Pour créer le noyau GKI pour l'architecture aarch64, consultez une branche Android Common Kernel antérieure à Android 13 et puis exécutez la commande suivante:

tools/bazel build //common:kernel_aarch64_dist

Pour créer une distribution, exécutez la commande suivante:

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

Par la suite, le binaire du noyau, les modules et les images correspondantes se trouvent dans le Répertoire $DIST_DIR. Si --dist_dir n'est pas spécifié, voir le résultat de la commande pour l'emplacement des artefacts. Pour en savoir plus, consultez les documentation sur AOSP.

Compiler avec build.sh (ancien)

Pour les branches correspondant à Android 12 ou version antérieure, OU branches sans Kleaf:

build/build.sh

Remarque: Les noyaux courants sont des noyaux génériques et personnalisables et ne définissent donc pas une configuration par défaut. Reportez-vous à la section Personnaliser le build du noyau pour savoir comment spécifier la configuration de compilation noyaux courants. Par exemple, pour créer le noyau GKI pour aarch64, plate-forme, exécutez:
$ BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh

Le binaire du noyau, les modules et l'image correspondante se trouvent dans le Répertoire out/BRANCH/dist.

Créer les modules du fournisseur pour l'appareil virtuel

Android 13 a introduit la création de noyaux avec Bazel (Kleaf) en remplacement de build.sh

Pour créer les modules de virtual_device, exécutez la commande suivante:

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

Pour créer une distribution, exécutez la commande suivante:

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

Pour en savoir plus sur la création de noyaux Android avec Bazel, consultez cette page. Kleaf : Building Android Kernels with Bazel

Pour en savoir plus sur la compatibilité de Kleaf avec les architectures individuelles, consultez Compatibilité avec Kleaf pour les appareils et les noyaux

Créer les modules du fournisseur pour l'appareil virtuel avec build.sh (ancien)

Dans Android 12, Cuttlefish et Goldfish s'entrecroisent. Ils partagent donc le même noyau: virtual_device. Pour compiler les modules de ce noyau, utilisez ce build configuration:

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

Android 11 lancé GKI, qui sépare le noyau en une image de noyau gérée par Google et en des modules gérés par le fournisseur, qui sont compilés séparément.

Voici un exemple de configuration d'image de noyau:

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

Cet exemple présente une configuration de module (Cuttlefish et Emulator):

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

Exécuter le noyau

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

Intégrer au build d'image Android

Copiez Image.lz4-dtb à l'emplacement du binaire du noyau correspondant. dans l'arborescence AOSP et recompilez l'image de démarrage.

Vous pouvez également définir TARGET_PREBUILT_KERNEL lorsque vous utilisez make bootimage (ou toute autre make qui crée une image de démarrage). Cette variable est pris en charge par tous les appareils, car il est configuré via device/common/populate-new-device.sh Exemple :

export TARGET_PREBUILT_KERNEL=DIST_DIR/Image.lz4-dtb

Noyaux Flash et de démarrage avec fastboot

La plupart des appareils récents ont une extension bootloader pour simplifier le processus de générer et démarrer une image de démarrage.

Pour démarrer le noyau sans le flasher, procédez comme suit:

adb reboot bootloader
fastboot boot Image.lz4-dtb

Avec cette méthode, le noyau n’est pas réellement flashé et ne persistera pas après un redémarrage.

Remarque:Les noms de noyau diffèrent selon l'appareil. Pour localiser le nom de fichier correct pour votre noyau, reportez-vous device/VENDOR/NAME-kernel dans l'arborescence AOSP.

Exécuter les noyaux sur Settlefish

Vous pouvez exécuter des noyaux dans l'architecture de votre choix Appareils seiches.

Pour démarrer un appareil seiche avec un ensemble spécifique de noyaux artefacts, exécutez la commande cvd start avec les artefacts du noyau cible en tant que paramètres. L'exemple de commande suivant utilise les artefacts du noyau pour une cible arm64 provenant du Fichier manifeste du noyau 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

Pour en savoir plus, consultez Développer les noyaux sur Settlefish.

Personnaliser la compilation du noyau

Pour personnaliser les builds de noyau pour les builds Kleaf, consultez Documentation Kleaf

Remarque:En général, le processus de compilation Kleaf n'est pas influencées par les variables d'environnement, mais par les options de ligne de commande et BUILD et définitions.

Personnaliser le build du noyau avec build.sh (ancien)

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

Variable d'environnement	Description	Exemple
`BUILD_CONFIG`	Fichier de configuration de compilation à partir duquel vous initialisez l'environnement de compilation. L'emplacement doit être défini par rapport à la racine du dépôt . La valeur par défaut est `build.config`. Obligatoire pour les noyaux courants.	`BUILD_CONFIG=common/build.config.gki.aarch64`
`CC`	Compilateur de remplacement à utiliser. Revenir à la valeur par défaut compilateur 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 compilation du noyau.	`OUT_DIR=/path/to/my/out`
`SKIP_DEFCONFIG`	Ignorer `make defconfig`	`SKIP_DEFCONFIG=1`
`SKIP_MRPROPER`	Ignorer `make mrproper`	`SKIP_MRPROPER=1`

Configuration de noyau personnalisée pour les builds locaux

Sous Android 14 et versions ultérieures, vous pouvez utiliser des fragments defconfig pour personnaliser les configurations du noyau. voir Documentation Kleaf sur les fragments defconfig

Configuration de noyau personnalisée pour les builds locaux avec des configurations de compilation (ancien)

Sous Android 13 et versions antérieures, consultez les informations ci-dessous.

Si vous devez changer régulièrement une option de configuration du noyau, par exemple, lorsque vous travaillez sur une fonctionnalité ou si vous avez besoin d'une option à définir pour le développement vous pouvez bénéficier de cette flexibilité en conservant ou une copie de la configuration de compilation.

Définissez la variable POST_DEFCONFIG_CMDS sur une instruction évaluée juste après l'étape habituelle de make defconfig est terminé. Comme les fichiers build.config proviennent du build les fonctions définies dans build.config peuvent être appelées dans les commandes post-defconfig.

Par exemple, il est fréquent de désactiver l'optimisation du délai d'association (LTO) pour le type de données cross-hatch. les noyaux pendant le développement. Bien que le LTO soit bénéfique pour les noyaux publiés, les frais généraux au moment de la compilation peuvent être importants. L'extrait suivant a été ajouté au build.config local désactive LTO de manière persistante lorsque avec 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)
}

Identifier les versions de noyau

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

Version du noyau à partir de l'arborescence AOSP

L'arborescence AOSP contient des versions de noyau prédéfinies. Le Git indique la version correcte dans le message de commit:

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

Si la version du noyau ne figure pas dans le journal git, obtenez-la auprès du système. comme décrit ci-dessous.

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

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

file kernel

Pour les fichiers Image.lz4-dtb, exécutez la commande suivante:

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

Créer une image de démarrage

Il est possible de créer une image de démarrage à l'aide de l'environnement de compilation du noyau.

Créer une image de démarrage pour les appareils avec init_boot

Pour les appareils avec la partition init_boot, l'image de démarrage est créée avec le noyau. L'image initramfs n'est pas intégrée dans l'image de démarrage.

Par exemple, avec Kleaf, vous pouvez créer l'image de démarrage GKI à l'aide de la commande suivante:

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

Avec build/build.sh (ancien paramètre), vous pouvez compiler l'image de démarrage GKI avec:

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

L'image de démarrage GKI se trouve dans $DIST_DIR.

Créer une image de démarrage pour les appareils sans init_boot (ancien)

Pour les appareils sans la partition init_boot, vous avez besoin d'un binaire ramdisk, que vous pouvez obtenir en téléchargement d'une image de démarrage GKI et à le décompresser. 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 $KERNEL_ROOT/out/ramdisk gki-ramdisk.lz4

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

Si vous développez avec AOSP main, vous pouvez télécharger Artefact de compilation ramdisk-recovery.img à partir d'une version aosp_arm64 ci.android.com et l'utiliser comme binaire ramdisk.

Lorsque vous disposez d'un binaire ramdisk et que vous l'avez copié dans gki-ramdisk.lz4 à la racine du build du noyau, vous pouvez générer une image de démarrage en exécutant la commande suivante:

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 utilisez une architecture basée sur x86, remplacez 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 de l'artefact $KERNEL_ROOT/out/$KERNEL_VERSION/dist

L'image de démarrage se trouve dans out/<kernel branch>/dist/boot.img.