Cette page détaille le processus de création de noyaux personnalisés pour les appareils Android. Ces instructions vous guident tout au long du processus de sélection des bonnes sources, de création 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 des sources de noyau plus récentes en utilisant Repo ; construisez-les sans configuration supplémentaire en exécutant build/build.sh à partir de la racine de votre extraction de source.
Téléchargement des sources et des outils de construction
Pour les noyaux récents, utilisez repo pour télécharger les sources, la chaîne d'outils et les scripts de construction. 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. L'utilisation de l'approche repo garantit une configuration correcte du répertoire source.
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 suivant répertorie les noms BRANCH pour les noyaux disponibles via cette méthode.
| Appareil | Chemin binaire dans l'arborescence AOSP | Succursales de mise en pension |
|---|---|---|
| Pixel 7 (panthère) Pixel 7 Pro (guépard) | appareil/google/pantah-kernel | android-gs-pantah-5.10-android13-qpr2 |
| Pixel 6a (geai bleu) | appareil/google/bluejay-kernel | android-gs-bluejay-5.10-android13-qpr2 |
| Pixel 6 (loriot) Pixel 6 Pro (corbeau) | device/google/raviole-kernel | android-gs-raviole-5.10-android13-qpr2 |
| Pixel 5a (barbet) Pixel 5 (redfin) Pixel 4a (5G) (ronce) | appareil/google/redbull-kernel | android-msm-redbull-4.19-android13-qpr2 |
| Pixel 4a (poisson-lune) | périphérique/google/sunfish-kernel | android-msm-sunfish-4.14-android13-qpr2 |
| Pixel 4 (flamme) Pixel 4 XL (corail) | périphérique/google/coral-kernel | android-msm-corail-4.14-android13 |
| Pixel 3a (sargo) Pixel 3a XL (bonite) | appareil/google/bonito-kernel | android-msm-bonito-4.9-android12L |
| Pixel 3 (ligne bleue) Pixel 3 XL (hachuré) | périphérique/google/crosshatch-kernel | android-msm-crosshatch-4.9-android12 |
| Pixel 2 (doré jaune) 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 | randonnée-linaro-android-4.14 randonnée-linaro-android-4.19 common-android12-5.4 common-android13-5.10 |
| 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 | common-android-4.4 common-android-4.9 common-android-4.14 common-android-4.19 common-android-4.19-stable common-android11-5.4 common-android12-5.4 common-android12-5.10 common-android13-5.10 common-android13-5.15 common-android14-5.15 common-android14-6.1 common-android-mainline |
Construire le noyau
Compilez ensuite le noyau avec ceci :
build/build.sh
Le binaire du noyau, les modules et l'image correspondante se trouvent dans le répertoire out/ BRANCH /dist .
Construire avec Bazel (Kleaf)
Android 13 a introduit les noyaux de construction avec Bazel , remplaçant build/build.sh .
Pour créer le noyau GKI pour l'architecture aarch64, consultez une branche Android Common Kernel au plus tôt sous Android 13, puis exécutez la commande suivante :
tools/bazel build //common:kernel_aarch64_dist
Pour créer une distribution, exécutez :
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é, consultez la sortie de la commande pour connaître l'emplacement des artefacts. Pour plus de détails, reportez-vous à la documentation sur AOSP .
Construire les modules du fournisseur pour le périphérique virtuel
Android 11 a introduit GKI , qui sépare le noyau en une image de noyau gérée par Google et des modules gérés par le fournisseur, 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 (Cuttlefish et Emulator) :
BUILD_CONFIG=common-modules/virtual-device/build.config.cuttlefish.x86_64 build/build.sh
Dans Android 12 Cuttlefish et Goldfish convergent, ils partagent donc le même noyau : virtual_device . Pour compiler les modules de ce noyau, utilisez cette configuration de compilation :
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.x86_64 build/build.sh
Android 13 a introduit les noyaux de construction avec Bazel (Kleaf), remplaçant build.sh .
Pour construire les modules de virtual_device , exécutez :
tools/bazel build //common-modules/virtual-device:virtual_device_x86_64_dist
Pour créer une distribution, exécutez :
tools/bazel run //common-modules/virtual-device:virtual_device_x86_64_dist -- --dist_dir=$DIST_DIR
Pour plus de détails sur la construction de noyaux Android avec Bazel, voir. Kleaf - Construire des noyaux Android avec Bazel .
Pour plus de détails sur la prise en charge de Kleaf pour les architectures individuelles, consultez Prise en charge de Kleaf pour les périphériques et les noyaux .
Prise en charge de Kleaf pour les périphériques et les noyaux
Le tableau suivant répertorie la prise en charge de Kleaf pour les noyaux de périphériques individuels. Pour les appareils non répertoriés, veuillez contacter le fabricant de l'appareil.
| Appareil | Succursales de mise en pension | Prise en charge de Kleaf | prise en charge build/build.sh |
|---|---|---|---|
| Noyau commun Android db845c Périphérique virtuel (x86_64, arm64) Périphérique virtuel (i686, bras) Rockpi4 | common-android-4.4 common-android-4.9 common-android-4.14 common-android-4.19 common-android-4.19-stable common-android11-5.4 common-android12-5.4 common-android12-5.10 | ❌ | ✅ |
| Noyau commun Android | common-android13-5.10 common-android13-5.15 | ✅ | ✅ (officiel) 1 |
| Noyau commun Android | common-android14-5.15 common-android14-6.1 common-android-mainline | ✅ | ❌ |
| db845c | common-android13-5.10 | ❌ | ✅ |
| db845c | common-android13-5.15 | ✅ | ✅ (officiel) 1 |
| db845c | common-android14-5.15 common-android14-6.1 common-android-mainline | ✅ | ❌ |
| Périphérique virtuel (x86_64, arm64) | common-android13-5.10 common-android13-5.15 | ✅ (officiel) 1 | ⚠️ (non maintenu) 2 |
| Périphérique virtuel (x86_64, arm64) | common-android14-5.15 common-android14-6.1 common-android-mainline | ✅ | ❌ |
| Périphérique virtuel (i686, bras) | common-android13-5.10 common-android13-5.15 | ❌ | ✅ |
| Périphérique virtuel (i686, bras) | common-android14-5.15 common-android14-6.1 common-android-mainline | ✅ | ❌ |
| Rockpi4 | common-android13-5.10 common-android13-5.15 | ❌ | ✅ |
| Rockpi4 | common-android14-5.15 common-android14-6.1 common-android-mainline | ✅ | ❌ |
| Hikey960 | randonnée-linaro-android-4.14 randonnée-linaro-android-4.19 common-android12-5.4 common-android13-5.10 | ❌ | ✅ |
| module fips140 | common-android12-5.10 common-android13-5.10 common-android13-5.15 | ❌ | ✅ |
| module fips140 | common-android14-5.15 | ✅ | ❌ |
1 « Officiel » signifie qu'il s'agit de la manière officielle de construire le noyau, même si la méthode alternative peut également être utilisée pour construire le noyau. 2 "Non maintenu" signifie que la construction du noyau avec cette méthode devrait fonctionner, mais la méthode de construction n'est pas continuellement testée. Il pourrait cesser de construire à l'avenir. Utilisez la méthode "officielle" pour construire à la place. | |||
Exécution du noyau
Il existe plusieurs façons d'exécuter un noyau personnalisé. Les moyens connus suivants sont adaptés à divers scénarios de développement.
Intégration dans la construction d'image Android
Copiez Image.lz4-dtb dans l'emplacement binaire du noyau respectif dans l'arborescence AOSP et reconstruisez l'image de démarrage.
Vous pouvez également définir la variable TARGET_PREBUILT_KERNEL lors de l'utilisation make bootimage (ou de toute autre ligne de commande make qui crée une image de démarrage). Cette variable est prise en charge par tous les appareils car elle est configurée via 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
La plupart des appareils récents ont une extension bootloader 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 bootloaderfastboot 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.
Personnalisation de la construction du noyau
Pour personnaliser les versions du noyau pour les versions de Kleaf, consultez la documentation de Kleaf .
Pour build/build.sh , le processus de construction 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 livrée avec une configuration par défaut appropriée. Les plus fréquemment utilisés sont listés ici. Pour une liste complète (et à jour), reportez-vous à build/build.sh .
| Variable d'environnement | Description | Exemple |
|---|---|---|
BUILD_CONFIG | Générez le fichier de configuration à partir duquel vous initialisez l'environnement de génération. L'emplacement doit être défini par rapport au répertoire racine du référentiel. Par défaut, build.config .Obligatoire pour les noyaux communs. | BUILD_CONFIG=common/build.config.gki.aarch64 |
CC | Remplacer le compilateur à utiliser. Revient au 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 | Ignorer make defconfig | SKIP_DEFCONFIG=1 |
SKIP_MRPROPER | make mrproper | SKIP_MRPROPER=1 |
Configuration personnalisée du noyau pour les builds locaux
Si vous avez besoin de changer régulièrement une option de configuration du noyau, par exemple lorsque vous travaillez sur une fonctionnalité, ou si vous avez besoin qu'une option soit définie à des fins de développement, vous pouvez obtenir cette flexibilité en conservant une modification locale ou une copie de la configuration de construction.
Définissez la variable POST_DEFCONFIG_CMDS sur une instruction qui est évaluée juste après l'étape habituelle make defconfig . Comme les fichiers build.config proviennent de l'environnement de construction, les fonctions définies dans build.config peuvent être appelées 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 hachurés pendant le développement. Bien que LTO soit bénéfique pour les noyaux publiés, la surcharge au moment de la construction peut être importante. L'extrait de code suivant ajouté au build.config local désactive LTO de manière 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 à compiler à 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édéfinies. Le journal git révèle la version correcte dans le cadre du message de validation :
cd $AOSP/device/VENDOR/NAMEgit 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 les fichiers Image.lz4-dtb , exécutez :
grep -a 'Linux version' Image.lz4-dtb
Création d'une image de démarrage
Il est possible de créer une image de démarrage à l'aide de l'environnement de génération du noyau.
Création d'une image de démarrage pour les périphériques avec init_boot
Pour les périphériques avec la partition init_boot , l'image de démarrage est construite avec le noyau. L'image initramfs n'est pas intégrée à l'image de démarrage.
Par exemple, avec Kleaf, vous pouvez créer l'image de démarrage GKI avec :
tools/bazel run //common:kernel_aarch64_dist -- --dist_dir=$DIST_DIR
Avec build/build.sh , vous pouvez créer 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éation d'une image de démarrage pour les périphériques sans init_boot
Pour les périphériques sans la partition init_boot , 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 $KERNEL_ROOT/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 AOSP, vous pouvez à la place télécharger l'artefact de construction ramdisk-recovery.img à partir d'une construction aosp_arm64 sur ci.android.com et l'utiliser comme binaire de disque virtuel.
Lorsque vous avez un binaire de disque virtuel et que vous l'avez copié dans gki-ramdisk.lz4 dans le répertoire racine de la construction 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 une architecture basée sur x86, remplacez Image par bzImage et aarch64 par 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'artefacts $KERNEL_ROOT/out/$KERNEL_VERSION/dist .
L'image de démarrage se trouve dans out/<kernel branch>/dist/boot.img .