Partition de démarrage générique

Sous Android 12, l'image générique boot, appelée image de noyau générique (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 conserve que le noyau GKI pour l'image boot.

Pour les appareils qui continuent à utiliser Android 12 ou une version de noyau antérieure, le ramdisk générique reste à sa place sans avoir à créer une nouvelle image init_boot.

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

Sur les appareils qui:

  • 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 diagrammes 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 passant 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, aucune récupération dédiée

Figure 1 : Appareils qui lancent ou passent à Android 13, avec GKI, sans récupération dédiée.

Démarrage 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 qui lancent ou passent à Android 13, avec GKI, récupération dédiée et A/B.

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

Démarrage 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 qui lancent ou passent à 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

Lancer/Mettre à niveau l'appareil, GKI, aucune récupération dédiée

Figure 4. Appareils lancés ou mis à niveau vers Android 12, avec GKI, aucune 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 qui lancent ou passent à Android 12, avec GKI, récupération dédiée et A/B.

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

Lancement ou mise à niveau vers 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 qui lancent ou passent à 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 de slot.

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

Lancement/mise à niveau de l'appareil, pas de GKI, récupération au démarrage

Figure 7. Appareils mis à niveau vers Android 12, pas de GKI, récupération en tant que démarrage.

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

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

Figure 8. Appareils mis à niveau vers Android 12, pas de GKI, récupération dédiée.

Contenu des images de démarrage

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

  • Image init_boot 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 d'en-tête V3 ou V4
      • Un boot_signature pour la certification du fichier boot.img GKI (version 4 uniquement). Le GKI boot.img certifié n'est pas signé pour le démarrage validé. Les OEM doivent toujours signer le boot.img prédéfini avec une clé AVB spécifique à l'appareil.
      • Générique cmdline (GENERIC_KERNEL_CMDLINE)
      • Kernel GKI
    • Image de ramdisk générique
      • N'inclut que les images boot d'Android 12 et versions antérieures

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

    • En-tête vendor_boot
      • cmdline spécifique à l'appareil (BOARD_KERNEL_CMDLINE)
    • Image ramdisk vendor_boot
      • lib/modules
      • Ressources de récupération (si aucune récupération dédiée)
    • Image dtb

  • Image recovery

    • Version 2 de l'en-tête
      • cmdline spécifique à l'appareil pour la récupération, le cas échéant
      • Pour une partition de récupération autre que A/B, le contenu de l'en-tête doit être autonome. Consultez la section Images de récupération. Exemple :
      • cmdline n'est pas concaténé à boot et vendor_boot cmdline.
      • L'en-tête spécifie la DTBO de récupération, si nécessaire.
      • Pour la partition de récupération A/B, les contenus peuvent être concatenatés ou inférés à partir 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.
    • Image ramdisk recovery
      • Ressources de récupération
      • Pour les partitions de récupération autres que A/B, le contenu du ramdisk doit être autonome. Consultez la section Images de récupération. Exemple :
      • lib/modules doit contenir tous les modules de noyau requis pour démarrer en mode de récupération.
      • Le disque RAM 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 kernel supplémentaires requis pour démarrer le mode de récupération, en plus des modules de kernel dans le ramdisk vendor_boot.
      • Le lien symbolique à /init peut exister, mais il est masqué par le binaire /init de premier niveau dans l'image de démarrage.

Contenu d'une image ramdisk générique

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

  • init
  • system/etc/ramdisk/build.prop
  • Accessoires ro.PRODUCT.bootimg.* build
  • Répertoires vides pour les points d'installation: debug_ramdisk/, mnt/, dev/, sys/, proc/ et metadata/
  • first_stage_ramdisk/
    • Répertoires vides dupliqués pour les points d'installation: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Intégration de l'image de démarrage

Les options de compilation contrôlent la manière dont les images init_boot, boot, recovery et vendor_boot sont compilées. La valeur d'une variable de tableau booléenne doit être la chaîne true ou être vide (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'affecte pas sysprops ni 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 ramdisk sont créées sur vendor_boot.

    • Si vous définissez ce paramètre sur true, les ressources de récupération sont créées pour vendor-ramdisk/ uniquement et ne sont pas créées pour recovery/root/.

    • Lorsqu'elles sont vides, les ressources de récupération sont créées pour recovery/root/ uniquement et ne sont pas créées pour vendor-ramdisk/.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. Cette variable contrôle si les clés AVB GSI sont créées sur vendor_boot.

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

      • est défini, les clés GSI AVB sont créées pour $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

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

    • Si cet élément est vide, si BOARD_RECOVERY_AS_ROOT:

      • est défini, 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 compilées pour $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. Cette variable contrôle si l'image recovery contient un noyau ou non. Les appareils qui démarrent avec Android 12 et qui utilisent la partition recovery A/B doivent définir cette variable sur true. Les appareils qui démarrent avec Android 12 et qui n'utilisent pas 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/ dans 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 en chaîne.

Combinaisons autorisées

Composant ou variable Mettre à niveau l'appareil sans partition de récupération Mettre à niveau l'appareil avec une partition de récupération Lancer l'appareil sans partition de récupération Lancer l'appareil avec la partition de récupération A/B Lancer l'appareil avec une partition de récupération autre qu'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 le laisser 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

Le paramètre vbmeta en chaîne doit être activé 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 ce changement.

Système en tant que racine

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. Le système en tant que racine n'est pas non plus compatible avec les appareils qui utilisent des partitions dynamiques.

Configurations de produit

Les appareils qui utilisent le ramdisk générique doivent installer une liste de fichiers autorisés à y être installés. 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-les plutôt vers vendor_ramdisk).

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 semblable à celle d'Android 12

  • Appareils qui passent à Android 12:

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

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur true. L'architecture est illustrée dans la Figure 3.

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur vide. L'architecture est comme illustrée dans la figure 4.

    • Vous pouvez définir BOARD_USES_RECOVERY_AS_BOOT sur vide. S'ils le font, ils utilisent de nouvelles configurations. Si ces appareils:

      • N'utilisez pas de partition recovery dédiée, l'architecture est 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 celle illustrée dans la figure 2a ou la figure 2b, et l'option de configuration de l'appareil est l'option 2a ou l'option 2b.

  • Les appareils équipés d'Android 12 doivent définir BOARD_USES_RECOVERY_AS_BOOT sur vide et utiliser de nouvelles configurations. Si de tels appareils:

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

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

Étant donné que aosp_arm64 crée uniquement GKI (et non vendor_boot ou 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 ramdisk vendor_boot contient toutes les ressources de récupération, y compris lib/modules (avec les modules de 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 ramdisk 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 récupération, le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de deuxième étape. Le contenu de vendor_boot + ramdisks génériques est le suivant:

  • /init (à partir d'un 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 installés dans le ramdisk générique vers vendor_ramdisk. Pour obtenir un exemple, consultez ce changement.

Installer des modules

Vous pouvez installer des modules spécifiques à l'appareil dans vendor_ramdisk (ignorez cette étape si vous n'avez aucun module spécifique à l'appareil à installer).

  • Utilisez la variante vendor_ramdisk du module lorsque le module s'installe sur le /first_stage_ramdisk. Ce module doit être disponible après que init a défini la racine sur /first_stage_ramdisk, mais avant que init ne définisse la racine sur /system. Pour obtenir des exemples, consultez les sections Sommes de contrôle des métadonnées et Compression virtuelle A/B.

  • Utilisez la variante recovery du module lorsque le module est installé dans /. Ce module doit être disponible avant que init ne bascule le root vers /first_stage_ramdisk. Pour en savoir plus sur l'installation de modules dans /, consultez la section Console de première étape.

Console de la première étape

Étant donné que la console de la première étape démarre avant que init ne passe de root à /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 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 s'installent sur $ANDROID_PRODUCT_OUT/recovery/root/system/bin, qui s'installe ensuite sur /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 s'installent dans $ANDROID_PRODUCT_OUT/recovery/root/system/bin, qui s'installe ensuite 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 prendre en charge 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 de modifications.

Compression A/B virtuelle

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 récupération ou en mode Android ne change pas, à l'exception de ce qui suit:

  • Le disque RAM build.prop se déplace dans /second_stage_resources afin que la deuxième étape, init, puisse lire l'horodatage de la compilation du démarrage.

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

Rendre e2fsck disponible

Les fichiers de compilation de l'appareil peuvent hériter de:

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

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

Les fichiers makefiles du produit installent $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. Au moment de l'exécution, le premier niveau init bascule 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 des plages recovery_a et recovery_b partition. Ces appareils incluent les appareils A/B et A/B virtuels dont la partition de récupération peut être mise à jour, avec la configuration suivante:

AB_OTA_PARTITIONS += recovery

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

  • Fichiers fstab spécifiques à l'appareil

  • lib/modules (inclut les modules de kernel 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 une partition recovery 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 := 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 dans /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 récupération, le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de deuxième étape.

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

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

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

  • /init (à partir d'un 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 disque RAM 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 dans vendor_ramdisk (ignorez cette étape si vous n'avez aucun module spécifique à 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 dans vendor_ramdisk, consultez Console de premier niveau, Sommes de contrôle des métadonnées et Compression A/B virtuelle.

Console de la première étape

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 s'installent sur $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, qui s'installe ensuite sur /system/bin sous vendor_ramdisk.

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Vous vous assurez ainsi que les modules spécifiés s'installent dans $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. Si le ramdisk vendor_boot est chargé en mode récupération, le module est également disponible dans recovery. Si le ramdisk vendor_boot n'est pas chargé en mode récupération, 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 de l'installation de la première étape, les appareils non compatibles avec GKI installent la variante ramdisk des modules suivants. Pour prendre en charge 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 de 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

Lors du démarrage sous Android, le processus de démarrage ne change pas. Le vendor_boot + ramdisk générique est semblable au processus de démarrage existant, à l'exception du fait 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.

Lorsque vous démarrez en mode récupération, le processus de démarrage change. La récupération + vendor_boot + le 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 en mode de récupération se déroule comme suit.

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

    1. Transfère la récupération + vendor_boot + le ramdisk générique vers /. (Si l'OEM duplique les kernel modules 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 ramdisk sur /, puis exécute /init à partir du ramdisk 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 de noyau du fournisseur à partir de /lib/modules.
    3. Appele DoFirstStageMount(), mais ignore l'installation, car IsRecoveryMode() == true. (L'appareil ne libère pas le 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 à partir du ramdisk recovery.

Rendre e2fsck disponible

Les fichiers de compilation de l'appareil peuvent hériter de:

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

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

Les fichiers makefiles du produit installent $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. Au moment 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 dotés d'une partition recovery autre que A/B. Autrement dit, l'appareil possède une partition nommée recovery sans suffixe d'emplacement. Ces appareils incluent:

  • Appareils autres qu'A/B
  • les appareils A/B et virtuels A/B, dont la partition de récupération n'est pas mise à jour. (C'est inhabituel.)

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

  • Fichiers fstab spécifiques à l'appareil
  • lib/modules (inclut les modules de noyau des fournisseurs)

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

  • Image du noyau
  • Image DTBO
  • Modules de noyau dans lib/modules
  • Initialisation de la première étape en tant que lien symbolique /init -> /system/bin/init
  • Binaire d'initialisation de deuxième étape /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 du tableau

Définissez les valeurs suivantes pour les appareils autres que les appareils 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 ramdisk 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 (de recovery ramdisk)
  • /system/bin/init (à partir du ramdisk recovery, compilé à partir de init_second_stage.recovery et exécuté à partir de /init)

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

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

Déplacer des fichiers fstab

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

Installer des modules

Vous pouvez installer des modules spécifiques à l'appareil dans le ramdisk vendor_ramdisk et recovery (ignorez cette étape si vous n'avez aucun module spécifique à 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 dans le ramdisk vendor_ramdisk et recovery, consultez Console de première étape et Sommes de contrôle des métadonnées.

Console de la première étape

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 s'installent sur $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, qui s'installe ensuite sur /system/bin sous vendor_ramdisk.

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Vous vous assurez ainsi que les modules spécifiés s'installent 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 de l'installation de la première étape de la récupération, activez la variante de récupération de ces modules et installez-les également.

Modifications apportées au processus de démarrage

Lorsque vous démarrez Android, le processus de démarrage ne change pas. Le vendor_boot + ramdisk générique est semblable au processus de démarrage existant, à l'exception du fait 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.

Lors du démarrage en mode récupération, le processus de démarrage ne change pas. Le disque RAM 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 en 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 ramdisk sur /, puis exécute /init, qui est un lien symbolique vers /system/bin/init à partir du ramdisk recovery.

  3. La première étape init démarre, puis effectue les opérations suivantes:

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

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 les informations de code temporel de la compilation.

  • Au moment de l'exécution, le premier niveau init copie les fichiers du ramdisk vers tmpfs avant de libérer le ramdisk afin que le deuxième niveau init puisse lire ce fichier pour définir les propriétés de code temporel de l'image boot.