Partition de démarrage générique

Dans Android 12, l'image boot générique, appelée Generic Kernel Image (GKI), contient le ramdisk générique et le noyau GKI.

Pour les appareils lancés avec Android 13, le ramdisk générique est supprimé de l'image boot et placé dans une image init_boot distincte. Cette modification ne laisse que le noyau GKI dans l'image boot.

Pour mettre à niveau les appareils qui continuent d'utiliser Android 12 ou des versions antérieures du noyau, le ramdisk générique reste à l'emplacement où il se trouvait, sans qu'une nouvelle image init_boot soit requise.

Pour créer un ramdisk générique, déplacez les ressources spécifiques au fournisseur hors du ramdisk de sorte que le ramdisk générique ne contienne que le init de la première étape et un fichier de propriétés contenant des informations d'horodatage.

Sur les appareils :

  • N'utilisez pas de partition recovery dédiée. Tous les bits de récupération sont déplacés du ramdisk générique vers le ramdisk vendor_boot.

  • Utilisez une partition recovery dédiée. Aucune modification du ramdisk recovery n'est nécessaire, car il est autonome.recovery

Architecture

Les schémas suivants illustrent l'architecture des appareils équipés d'Android 12 ou version ultérieure. Les appareils lancés avec Android 13 disposent d'une nouvelle image init_boot contenant le ramdisk générique. Les appareils qui passent d'Android 12 à Android 13 utilisent la même architecture qu'avec Android 12.

Lancement avec Android 13, sans récupération dédiée

Lancement/mise à niveau de l'appareil, GKI, sans récupération dédiée

Figure 1 : Appareils lancés ou mis à niveau vers Android 13, avec GKI, sans récupération dédiée.

Lancement avec Android 13, récupération dédiée et A/B (ramdisk dédié)

Lancement/mise à niveau de l'appareil, GKI, récupération dédiée et A/B

Figure 2. Appareils lancés ou mis à niveau vers Android 13, avec GKI, récupération dédiée et A/B.

Reportez-vous à cette figure si l'appareil comporte des partitions recovery_a et recovery_b.

Lancement avec Android 13, récupération dédiée et non A/B (ramdisk dédié)

Lancement/mise à niveau de l'appareil, GKI, récupération dédiée et non A/B

Figure 3. Appareils lancés ou mis à niveau vers Android 13, avec GKI, récupération dédiée et non A/B.

Reportez-vous à cette figure si l'appareil comporte une partition nommée recovery sans suffixe d'emplacement.

Lancement ou mise à niveau vers Android 12, sans récupération dédiée

Lancement/mise à niveau de l'appareil, GKI, sans récupération dédiée

Figure 4. Appareils lancés ou mis à niveau vers Android 12, avec GKI, sans récupération dédiée.

Lancement ou mise à niveau vers Android 12, récupération dédiée et A/B (ramdisk dédié)

Lancement/mise à niveau de l'appareil, GKI, récupération dédiée et A/B

Figure 5. Appareils lancés ou mis à niveau vers Android 12, avec GKI, récupération dédiée et A/B.

Reportez-vous à cette figure si l'appareil comporte des partitions recovery_a et recovery_b.

Lancer ou passer à Android 12, récupération dédiée et non A/B (ramdisk dédié)

Lancement/mise à niveau de l'appareil, GKI, récupération dédiée et non A/B

Figure 6. Appareils lancés ou mis à niveau vers Android 12, avec GKI, récupération dédiée et non A/B.

Reportez-vous à cette figure si l'appareil comporte une partition nommée recovery sans suffixe d'emplacement.

Mise à niveau vers Android 12, recovery-as-boot (recovery-as-ramdisk)

Lancement/mise à niveau de l'appareil, pas de GKI, recovery-as-boot

Figure 7. Appareils mis à niveau vers Android 12, sans GKI, avec recovery-as-boot.

Mise à niveau vers Android 12, récupération dédiée (ramdisk dédié)

Lancement/Mise à niveau de l'appareil, sans GKI, récupération dédiée

Figure 8. Appareils passant à Android 12, sans GKI, avec une récupération dédiée.

Contenu des images de démarrage

Les images de démarrage Android contiennent les éléments suivants.

  • init_boot Image ajoutée pour les appareils lancés avec Android 13

    • Version de l'en-tête V4
    • Image ramdisk générique

  • Image boot générique

    • Version de l'en-tête V3 ou V4
      • boot_signature pour la certification GKI boot.img (v4 uniquement). Le GKI certifié boot.img n'est pas signé pour le démarrage validé. Les OEM doivent toujours signer le boot.img précompilé avec une clé AVB spécifique à l'appareil.
      • Générique cmdline (GENERIC_KERNEL_CMDLINE)
      • Noyau GKI
    • Image ramdisk générique
      • Inclus uniquement dans les images boot d'Android 12 et versions antérieures

  • Image vendor_boot (pour en savoir plus, consultez Partitions de démarrage du fournisseur)

    • vendor_boot header
      • cmdline spécifique à l'appareil (BOARD_KERNEL_CMDLINE)
    • vendor_boot image ramdisk
      • lib/modules
      • Ressources de récupération (si aucune récupération dédiée)
    • dtb image

  • recovery image

    • Version 2 de l'en-tête
      • cmdline spécifique à l'appareil pour la récupération, si nécessaire
      • Pour une partition de récupération non A/B, le contenu de l'en-tête doit être autonome. Pour en savoir plus, consultez Images de récupération. Exemple :
      • cmdline n'est pas concaténé à boot et vendor_boot cmdline.
      • L'en-tête spécifie le DTBO de récupération, si nécessaire.
      • Pour la partition de récupération A/B, le contenu peut être concaténé ou déduit de boot et vendor_boot. Exemple :
      • cmdline est concaténé à boot et vendor_boot cmdline.
      • Le DTBO peut être déduit de l'en-tête vendor_boot.
    • recovery image ramdisk
      • Ressources de récupération
      • Pour une partition de récupération non A/B, le contenu du ramdisk doit être autonome. Consultez Images de récupération. Exemple :
      • lib/modules doit contenir tous les modules de noyau nécessaires au démarrage du mode Recovery.
      • Le ramdisk de récupération doit contenir init.
      • Pour la partition de récupération A/B, le ramdisk de récupération est ajouté au ramdisk générique et vendor_boot. Il n'a donc pas besoin d'être autonome. Exemple :
      • lib/modules ne peut contenir que des modules de noyau supplémentaires nécessaires au démarrage du mode Recovery, en plus des modules de noyau du ramdisk vendor_boot.
      • Le lien symbolique à /init peut exister, mais il est masqué par le binaire /init de première étape dans l'image de démarrage.

Contenu de l'image ramdisk générique

Le ramdisk générique contient les composants suivants.

  • init
  • system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build accessoires
  • Répertoires vides pour les points de montage : debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/
  • first_stage_ramdisk/
    • Répertoires vides dupliqués pour les points de montage : debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Intégration de l'image de démarrage

Les indicateurs de compilation contrôlent la façon dont les images init_boot, boot, recovery et vendor_boot sont créées. La valeur d'une variable booléenne du tableau doit être la chaîne true ou être vide (valeur par défaut).

  • TARGET_NO_KERNEL : cette variable indique si la compilation utilise une image de démarrage prédéfinie. Si cette variable est définie sur true, définissez BOARD_PREBUILT_BOOTIMAGE sur l'emplacement de l'image de démarrage prédéfinie (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img).

  • BOARD_USES_RECOVERY_AS_BOOT. Cette variable indique si l'appareil utilise l'image recovery comme image boot. Lorsque vous utilisez GKI, cette variable est vide et les ressources de récupération doivent être déplacées vers vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE. Cette variable indique que la carte utilise GKI. Cette variable n'a aucune incidence sur les propriétés système ni sur PRODUCT_PACKAGES.

    Il s'agit du commutateur GKI au niveau de la carte. Toutes les variables suivantes sont limitées par cette variable.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. Cette variable contrôle si les ressources de récupération du disque RAM sont compilées dans vendor_boot.

    • Lorsqu'il est défini sur true, les ressources de récupération sont créées uniquement pour vendor-ramdisk/ et non pour recovery/root/.

    • Lorsqu'il est vide, les ressources de récupération sont créées uniquement pour recovery/root/ et non pour vendor-ramdisk/.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. Cette variable détermine si les clés GSI AVB sont créées pour vendor_boot.

    • Si la valeur est définie sur true, si BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

      • Si elle est définie, les clés AVB GSI sont conçues pour $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

      • Si elle n'est pas définie, les clés AVB GSI sont créées sur $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

    • Si la valeur est vide et que BOARD_RECOVERY_AS_ROOT :

      • Si elle est définie, les clés AVB GSI sont conçues pour $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

      • Si elle n'est pas définie, les clés AVB GSI sont créées sur $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE : cette variable indique si l'image recovery contient un noyau ou non. Les appareils lancés avec Android 12 et utilisant une partition A/B recovery doivent définir cette variable sur true. Les appareils lancés avec Android 12 et utilisant un système non A/B doivent définir cette variable sur false pour que l'image de récupération reste autonome.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. Cette variable contrôle si $OUT/boot*.img est copié dans IMAGES/ sous les fichiers cibles.

    • aosp_arm64 doit définir cette variable sur true.

    • Les autres appareils doivent laisser cette variable vide.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Cette variable contrôle si init_boot.img est généré et définit la taille. Lorsqu'il est défini, le ramdisk générique est ajouté à init_boot.img au lieu de boot.img et nécessite que les variables BOARD_AVB_INIT_BOOT* soient définies pour vbmeta chaîné.

Combinaisons autorisées

Composant ou variable Mettre à niveau un appareil sans partition de récupération Mettre à niveau un appareil avec une partition de récupération Lancer l'appareil sans partition de récupération Lancer l'appareil avec une partition de récupération A/B Lancer l'appareil avec une partition de récupération non A/B aosp_arm64
Inclut boot oui Oui Oui Oui Oui oui
Contient init_boot (Android 13) non non oui Oui Oui oui
Inclut vendor_boot facultatif facultatif oui Oui oui non
Inclut recovery non oui non oui oui non
BOARD_USES_RECOVERY_AS_BOOT true vide vide vide vide vide
BOARD_USES_GENERIC_KERNEL_IMAGE vide vide true true true true
PRODUCT_BUILD_RECOVERY_IMAGE vide true ou vide vide true ou vide true ou vide vide
BOARD_RECOVERYIMAGE_PARTITION_SIZE vide > 0 vide > 0 > 0 vide
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT vide vide true vide vide vide
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT vide vide true true true vide
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE vide vide vide true vide vide
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES vide vide vide vide vide true

Les appareils disposant d'une partition recovery dédiée peuvent définir PRODUCT_BUILD_RECOVERY_IMAGE sur true ou sur une valeur vide. Pour ces appareils, si BOARD_RECOVERYIMAGE_PARTITION_SIZE est défini, une image recovery est créée.

Activer vbmeta en chaîne pour le démarrage

La vbmeta chaînée doit être activée pour les images boot et init_boot. Spécifiez les éléments suivants :

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

Pour obtenir un exemple, consultez cette modification.

System-as-root

Le système en tant que racine n'est pas compatible avec les appareils qui utilisent GKI. Sur ces appareils, BOARD_BUILD_SYSTEM_ROOT_IMAGE doit être vide. System-as-root n'est pas non plus compatible avec les appareils qui utilisent des partitions dynamiques.

Configurations de produits

Les appareils qui utilisent le ramdisk générique doivent installer une liste de fichiers autorisés à être installés sur le ramdisk. Pour ce faire, spécifiez les éléments suivants dans device.mk :

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

Le fichier generic_ramdisk.mk empêche également d'autres fichiers makefile d'installer accidentellement d'autres fichiers sur le disque RAM (déplacez ces fichiers vers vendor_ramdisk à la place).

Configurer des appareils

Les instructions de configuration diffèrent selon que l'appareil est lancé avec Android 13, mis à niveau vers Android 12 ou lancé avec Android 12. Android 13, la configuration est similaire à celle d'Android 12.

  • Appareils passant à Android 12 :

    • Peut conserver la valeur de BOARD_USES_RECOVERY_AS_BOOT. Si c'est le cas, ils utilisent des configurations anciennes et les nouvelles variables de compilation doivent être vides. Si ces appareils :

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur true. L'architecture est alors celle illustrée à la figure 3.

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur "empty" (vide). L'architecture est alors celle illustrée dans la figure 4.

    • Vous pouvez définir BOARD_USES_RECOVERY_AS_BOOT sur une valeur vide. Si c'est le cas, ils utilisent de nouvelles configurations. Si ces appareils :

      • N'utilisez pas de partition recovery dédiée. L'architecture est celle illustrée dans la Figure 1 et l'option de configuration de l'appareil est l'Option 1.

      • Utilisez une partition recovery dédiée. L'architecture est illustrée dans la figure 2a ou la figure 2b, et l'option de configuration de l'appareil est Option 2a ou Option 2b.

  • Les appareils lancés avec Android 12 doivent définir BOARD_USES_RECOVERY_AS_BOOT sur une valeur vide et utiliser de nouvelles configurations. Si ces appareils :

    • N'utilisez pas de partition recovery dédiée. L'architecture est celle illustrée dans la figure 1 et l'option de configuration de l'appareil est l'option 1.

    • Utilisez une partition recovery dédiée. L'architecture est illustrée dans la Figure 2a ou la Figure 2b, et l'option de configuration de l'appareil est Option 2a ou Option 2b.

Étant donné que aosp_arm64 ne crée que GKI (et non vendor_boot ni la récupération), il ne s'agit pas d'une cible complète. Pour les configurations de compilation aosp_arm64, consultez generic_arm64.

Option 1 : Aucune partition de récupération dédiée

Les appareils sans partition recovery contiennent l'image boot générique dans la partition boot. Le disque RAM vendor_boot contient toutes les ressources de récupération, y compris lib/modules (avec les modules du noyau du fournisseur). Sur ces appareils, la configuration du produit hérite de generic_ramdisk.mk.

Définir les valeurs BOARD

Définissez les valeurs suivantes :

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Le disque RAM vendor_boot peut contenir un lien symbolique /init vers /system/bin/init et init_second_stage.recovery à /system/bin/init. Toutefois, comme le ramdisk générique est concaténé après le ramdisk vendor_boot, le lien symbolique /init est écrasé. Lorsque l'appareil démarre en mode Recovery, le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de la deuxième étape. Le contenu de vendor_boot et des ramdisks génériques est le suivant :

  • /init (à partir du ramdisk générique, créé à partir de init_first_stage)
  • /system/bin/init (à partir de vendor_ramdisk, créé à partir de init_second_stage.recovery)

Déplacer des fichiers fstab

Déplacez tous les fichiers fstab qui ont été installés sur le ramdisk générique vers vendor_ramdisk. Pour obtenir un exemple, consultez cette modification.

Installer des modules

Vous pouvez installer des modules spécifiques à l'appareil sur vendor_ramdisk (ignorez cette étape si vous n'avez pas de modules spécifiques à l'appareil à installer).

  • Utilisez la variante vendor_ramdisk du module lorsque le module est installé dans /first_stage_ramdisk. Ce module devrait être disponible après que init passe à /first_stage_ramdisk, mais avant que init passe à /system. Pour obtenir des exemples, consultez Sommes de contrôle des métadonnées et Compression A/B virtuelle.

  • Utilisez la variante recovery du module lorsque le module est installé sur /. Ce module doit être disponible avant que init ne passe à /first_stage_ramdisk. Pour savoir comment installer des modules sur /, consultez Console de première phase.

Console de la première phase

Étant donné que la console de la première étape démarre avant que init ne bascule la racine dans /first_stage_ramdisk, vous devez installer la variante recovery des modules. Par défaut, les deux variantes de module sont installées dans build/make/target/product/base_vendor.mk. Par conséquent, si le fichier makefile de l'appareil hérite de ce fichier, vous n'avez pas besoin d'installer explicitement la variante recovery.

Pour installer explicitement les modules de récupération, utilisez la commande suivante.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Cela garantit que linker, sh et toybox sont installés dans $ANDROID_PRODUCT_OUT/recovery/root/system/bin, qui est ensuite installé dans /system/bin sous vendor_ramdisk.

Pour ajouter les modules nécessaires à la console de première étape (par exemple, adbd), utilisez la commande suivante.

PRODUCT_PACKAGES += adbd.recovery

Cela garantit que les modules spécifiés sont installés dans $ANDROID_PRODUCT_OUT/recovery/root/system/bin, qui est ensuite installé dans /system/bin sous vendor_ramdisk.

Sommes de contrôle des métadonnées

Pour prendre en charge les sommes de contrôle des métadonnées lors du montage de la première étape, les appareils qui ne sont pas compatibles avec GKI installent la variante ramdisk des modules suivants. Pour ajouter la prise en charge de GKI, déplacez les modules vers $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin :

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Pour obtenir un exemple, consultez cette liste des modifications.

Compression virtuelle A/B

Pour prendre en charge la compression A/B virtuelle, snapuserd doit être installé sur vendor_ramdisk. L'appareil doit hériter de virtual_ab_ota/compression.mk, qui installe la variante vendor_ramdisk de snapuserd.

Modifications apportées au processus de démarrage

Le processus de démarrage en mode Recovery ou dans Android ne change pas, à l'exception de ce qui suit :

  • Le ramdisk build.prop passe à /second_stage_resources afin que la deuxième étape init puisse lire le code temporel de compilation du démarrage.

Étant donné que les ressources passent du ramdisk générique au ramdisk vendor_boot, le résultat de la concaténation du ramdisk générique au ramdisk vendor_boot ne change pas.

Rendre e2fsck disponible

Les fichiers make de l'appareil peuvent hériter des éléments suivants :

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk si l'appareil est compatible avec les tests A/B virtuels, mais pas avec la compression.

  • virtual_ab_ota/compression.mk si l'appareil est compatible avec la compression A/B virtuelle.

Les fichiers makefile du produit installent $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. Lors de l'exécution, la première étape init transforme la racine en /first_stage_ramdisk, puis exécute /system/bin/e2fsck.

Option 2a : Partition de récupération dédiée et A/B

Utilisez cette option pour les appareils avec des partitions A/B recovery, c'est-à-dire que l'appareil possède une partition recovery_a et une partition recovery_b partition. Ces appareils incluent les appareils A/B et Virtual A/B dont la partition de récupération est modifiable, avec la configuration suivante :

AB_OTA_PARTITIONS += recovery

Le ramdisk vendor_boot contient les bits du fournisseur du ramdisk et les modules du noyau du fournisseur, y compris les éléments suivants :

  • Fichiers fstab spécifiques à l'appareil

  • lib/modules (inclut les modules du noyau du fournisseur)

Le ramdisk recovery contient toutes les ressources de récupération. Sur ces appareils, la configuration du produit hérite de generic_ramdisk.mk.

Définir les valeurs BOARD

Définissez les valeurs suivantes pour les appareils avec partition A/B recovery :

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Le ramdisk recovery peut contenir un lien symbolique /init -> /system/bin/init et init_second_stage.recovery à /system/bin/init. Toutefois, comme le ramdisk de démarrage est concaténé après le ramdisk recovery, le lien symbolique /init est écrasé. Lorsque l'appareil démarre en mode Recovery, le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de la deuxième étape.

Lorsque l'appareil démarre dans recovery, le contenu de recovery + vendor_boot + les ramdisks génériques est le suivant :

  • /init (à partir du disque RAM, créé à partir de init_first_stage)
  • /system/bin/init (à partir du ramdisk recovery, créé à partir de init_second_stage.recovery et exécuté à partir de /init)

Lorsque l'appareil démarre sous Android, le contenu de vendor_boot + les ramdisques génériques est le suivant :

  • /init (à partir du ramdisk générique, créé à partir de init_first_stage)

Déplacer des fichiers fstab

Déplacez tous les fichiers fstab installés sur le ramdisk générique vers vendor_ramdisk. Pour obtenir un exemple, consultez cette modification.

Installer des modules

Si vous le souhaitez, vous pouvez installer des modules spécifiques à l'appareil sur vendor_ramdisk (ignorez cette étape si vous n'avez pas de modules spécifiques à l'appareil à installer). Init ne change pas de racine. La variante vendor_ramdisk des modules s'installe à la racine de vendor_ramdisk. Pour obtenir des exemples d'installation de modules sur vendor_ramdisk, consultez Console de première phase, Sommes de contrôle des métadonnées et Compression A/B virtuelle.

Console de la première phase

Pour installer la variante vendor_ramdisk des modules, utilisez la commande suivante :

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Cela garantit que linker, sh et toybox sont installés dans $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, qui est ensuite installé dans /system/bin sous vendor_ramdisk.

Pour ajouter les modules nécessaires à la console de la première étape (par exemple, adbd), activez la variante vendor_ramdisk de ces modules en important les correctifs correspondants dans AOSP, puis utilisez les éléments suivants :

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Cela garantit que les modules spécifiés sont installés dans $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. Si le ramdisk vendor_boot est chargé en mode Recovery, le module est également disponible dans recovery. Si le ramdisk vendor_boot n'est pas chargé en mode Recovery, l'appareil peut également installer adbd.recovery.

Sommes de contrôle des métadonnées

Pour prendre en charge les sommes de contrôle des métadonnées lors du montage de la première étape, les appareils qui ne sont pas compatibles avec GKI installent la variante ramdisk des modules suivants. Pour ajouter la prise en charge de GKI, déplacez les modules vers $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin :

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Pour obtenir un exemple, consultez cette liste des modifications.

Compression virtuelle A/B

Pour prendre en charge la compression A/B virtuelle, snapuserd doit être installé sur vendor_ramdisk. L'appareil doit hériter de virtual_ab_ota/compression.mk, qui installe la variante vendor_ramdisk de snapuserd.

Modifications apportées au processus de démarrage

Le processus de démarrage dans Android ne change pas. Le ramdisk générique vendor_boot est semblable au processus de démarrage existant, sauf que fstab se charge à partir de vendor_boot. Comme system/bin/recovery n'existe pas, first_stage_init le gère comme un démarrage normal.

Le processus de démarrage change lorsque vous démarrez en mode Recovery. La récupération + vendor_boot + ramdisk générique est semblable au processus de récupération existant, mais le noyau est chargé à partir de l'image boot au lieu de l'image recovery. Le processus de démarrage du mode Récupération est le suivant.

  1. Le bootloader démarre, puis effectue les opérations suivantes :

    1. Envoie la récupération + vendor_boot + ramdisk générique à /. (Si l'OEM duplique les modules du noyau dans le ramdisk de récupération en les ajoutant à BOARD_RECOVERY_KERNEL_MODULES, vendor_boot est facultatif.)
    2. Exécute le noyau à partir de la partition boot.

  2. Le noyau monte le disque RAM sur /, puis exécute /init à partir du disque RAM générique.

  3. L'initialisation de la première étape commence, puis effectue les opérations suivantes :

    1. Définit IsRecoveryMode() == true et ForceNormalBoot() == false.
    2. Charge les modules du noyau du fournisseur à partir de /lib/modules.
    3. Appelle DoFirstStageMount(), mais ignore le montage, car IsRecoveryMode() == true. (L'appareil ne libère pas de ramdisk (car / est toujours le même), mais appelle SetInitAvbVersionInRecovery().)
    4. Démarre l'initialisation de la deuxième étape à partir de /system/bin/init depuis le disque RAM recovery.

Rendre e2fsck disponible

Les fichiers make de l'appareil peuvent hériter des éléments suivants :

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk si l'appareil est compatible avec les tests A/B virtuels, mais pas avec la compression.

  • virtual_ab_ota/compression.mk si l'appareil est compatible avec la compression A/B virtuelle.

Les fichiers makefile du produit installent $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. Lors de l'exécution, la première étape init exécute /system/bin/e2fsck.

Option 2b : Partition de récupération dédiée et non A/B

Utilisez cette option pour les appareils avec une partition recovery non A/B, c'est-à-dire que l'appareil possède une partition nommée recovery sans suffixe d'emplacement. Voici quelques exemples d'appareils concernés :

  • appareils non A/B ;
  • Appareils A/B et A/B virtuel, dont la partition de récupération ne peut pas être mise à jour. (C'est inhabituel.)

Le ramdisk vendor_boot contient les bits du fournisseur du ramdisk et les modules du noyau du fournisseur, y compris les éléments suivants :

  • Fichiers fstab spécifiques à l'appareil
  • lib/modules (inclut les modules du noyau du fournisseur)

L'image recovery doit être autonome. Il doit contenir toutes les ressources requises pour démarrer le mode Restauration, y compris :

  • Image du noyau
  • Image DTBO
  • Modules du noyau dans lib/modules
  • Init de première étape en tant que lien symbolique /init -> /system/bin/init
  • Binaire init de deuxième phase /system/bin/init
  • Fichiers fstab spécifiques à l'appareil
  • Toutes les autres ressources de récupération, y compris le binaire recovery

Sur ces appareils, la configuration du produit hérite de generic_ramdisk.mk.

Définir les valeurs BOARD

Définissez les valeurs suivantes pour les appareils non A/B :

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Le disque RAM recovery doit contenir un lien symbolique /init -> /system/bin/init et init_second_stage.recovery à /system/bin/init. Lorsque l'appareil démarre en mode récupération, le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de la première et de la deuxième étape.

Lorsque l'appareil démarre dans recovery, le contenu des ramdisks recovery est le suivant :

  • /init -> /system/bin/init (à partir du ramdisk recovery)
  • /system/bin/init (à partir du ramdisk recovery, créé à partir de init_second_stage.recovery et exécuté à partir de /init)

Lorsque l'appareil démarre sous Android, le contenu de vendor_boot + les ramdisques génériques est le suivant :

  • /init (à partir du disque RAM, créé à partir de init_first_stage)

Déplacer des fichiers fstab

Déplacez tous les fichiers fstab qui ont été installés sur le ramdisk générique vers les ramdisks vendor_ramdisk et recovery. Pour obtenir un exemple, consultez cette modification.

Installer des modules

Vous pouvez installer des modules spécifiques à l'appareil sur les ramdisks vendor_ramdisk et recovery (ignorez cette étape si vous n'avez pas de modules spécifiques à l'appareil à installer). init ne change pas de racine. La variante vendor_ramdisk des modules s'installe à la racine de vendor_ramdisk. La variante recovery des modules s'installe à la racine du ramdisk recovery. Pour obtenir des exemples d'installation de modules sur les ramdisks vendor_ramdisk et recovery, consultez Console de première étape et Sommes de contrôle des métadonnées.

Console de la première phase

Pour installer la variante vendor_ramdisk des modules, utilisez la commande suivante :

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Cela garantit que linker, sh et toybox sont installés dans $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, qui est ensuite installé dans /system/bin sous vendor_ramdisk.

Pour ajouter les modules nécessaires à la console de la première étape (par exemple, adbd), activez la variante vendor_ramdisk de ces modules en important les correctifs correspondants dans AOSP, puis utilisez les éléments suivants :

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Cela garantit que les modules spécifiés sont installés dans $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin.

Pour installer la variante recovery des modules, remplacez vendor_ramdisk par recovery :

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

Sommes de contrôle des métadonnées

Pour prendre en charge les sommes de contrôle des métadonnées lors du montage de la première étape, les appareils qui ne sont pas compatibles avec GKI installent la variante ramdisk des modules suivants. Pour ajouter la prise en charge de GKI, déplacez les modules vers $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin :

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Pour prendre en charge les sommes de contrôle des métadonnées lors du montage de la première étape en mode Recovery, activez la variante Recovery de ces modules et installez-les également.

Modifications apportées au processus de démarrage

Le processus de démarrage dans Android ne change pas. Le ramdisk générique vendor_boot est semblable au processus de démarrage existant, sauf que fstab se charge à partir de vendor_boot. Comme system/bin/recovery n'existe pas, first_stage_init le gère comme un démarrage normal.

Le processus de démarrage ne change pas lorsque vous démarrez en mode Recovery. Le ramdisk de récupération est chargé de la même manière que le processus de récupération existant. Le noyau est chargé à partir de l'image recovery. Le processus de démarrage du mode Récupération est le suivant.

  1. Le bootloader démarre, puis effectue les opérations suivantes :

    1. Transfère le ramdisk de récupération vers /.
    2. Exécute le noyau à partir de la partition recovery.

  2. Le noyau monte le disque RAM sur /, puis exécute /init, qui est un lien symbolique vers /system/bin/init à partir du disque RAM recovery.

  3. L'initialisation de la première étape commence, puis effectue les opérations suivantes :

    1. Définit IsRecoveryMode() == true et ForceNormalBoot() == false.
    2. Charge les modules du noyau du fournisseur à partir de /lib/modules.
    3. Appelle DoFirstStageMount(), mais ignore le montage, car IsRecoveryMode() == true. (L'appareil ne libère pas de ramdisk (car / est toujours le même), mais appelle SetInitAvbVersionInRecovery().)
    4. Démarre l'initialisation de la deuxième étape à partir de /system/bin/init depuis le disque RAM recovery.

Codes temporels de l'image de démarrage

Le code suivant est un exemple de fichier d'horodatage d'image boot :

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • Au moment de la compilation, un fichier system/etc/ramdisk/build.prop est ajouté au ramdisk générique. Ce fichier contient des informations d'horodatage de la compilation.

  • Lors de l'exécution, la première étape init copie les fichiers du disque RAM vers tmpfs avant de libérer le disque RAM afin que la deuxième étape init puisse lire ce fichier pour définir les propriétés d'horodatage de l'image boot.