Partition de démarrage générique

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

Pour les appareils lancés avec Android 13, le disque virtuel générique est supprimé de l’image boot et placé dans une image init_boot distincte. Ce changement laisse l'image boot avec uniquement le noyau GKI.

Pour la mise à niveau des appareils qui continuent à utiliser Android 12 ou des versions antérieures du noyau, le disque virtuel générique reste là où il se trouvait sans nécessiter une nouvelle image init_boot .

Pour créer un disque virtuel générique, déplacez les ressources spécifiques au fournisseur hors du disque virtuel de telle sorte que le disque virtuel générique contienne uniquement 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 disque virtuel générique vers le disque virtuel vendor_boot .

  • Utilisez une partition recovery dédiée, aucune modification du disque virtuel recovery n'est nécessaire car le disque virtuel recovery est autonome.

Architecture

Les diagrammes suivants illustrent l'architecture des appareils exécutant Android 12 et versions ultérieures. Les appareils lancés avec Android 13 ont une nouvelle image init_boot contenant le disque virtuel générique. Les appareils mis à niveau d’Android 12 vers Android 13 utilisent la même architecture qu’avec Android 12.

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

Appareil de lancement/mise à niveau, GKI, pas de récupération dédiée

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

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

Appareil de lancement/mise à niveau, GKI, récupération dédiée et A/B

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

Reportez-vous à cette figure si le périphérique possède des partitions recovery_a et recovery_b .

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

Appareil de lancement/mise à niveau, 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 le périphérique dispose d'une partition nommée recovery sans suffixe d'emplacement.

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

Appareil de lancement/mise à niveau, GKI, pas de récupération dédiée

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

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

Appareil de lancement/mise à niveau, GKI, récupération dédiée et A/B

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

Reportez-vous à cette figure si le périphérique possède des partitions recovery_a et recovery_b .

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

Appareil de lancement/mise à niveau, 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 le périphérique dispose d'une partition nommée recovery sans suffixe d'emplacement.

Mise à niveau vers Android 12, récupération au démarrage (récupération en tant que disque virtuel)

Dispositif de lancement/mise à niveau, pas de GKI, récupération au démarrage

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

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

Appareil de lancement/mise à niveau, 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 d'en-tête V4
    • Image de disque virtuel générique

  • Image boot générique

    • Version d'en-tête V3 ou V4
      • Une boot_signature pour la certification GKI boot.img (v4 uniquement). Le boot.img GKI certifié n'est pas signé pour un démarrage vérifié. Les OEM doivent toujours signer le boot.img prédéfini avec une clé AVB spécifique au périphérique.
      • cmdline générique ( GENERIC_KERNEL_CMDLINE )
      • Noyau GKI
    • Image de disque virtuel générique
      • Inclus uniquement dans les images boot d'Android 12 et versions antérieures

  • Image vendor_boot (pour plus de détails, voir Partitions de démarrage du fournisseur )

    • en-tête vendor_boot
      • cmdline spécifique à l'appareil ( BOARD_KERNEL_CMDLINE )
    • image du disque virtuel vendor_boot
      • lib/modules
      • Ressources de récupération (si pas de récupération dédiée)
    • image dtb

  • image recovery

    • En-tête version V2
      • cmdline spécifique à l'appareil pour la récupération, si nécessaire
      • Pour les partitions de récupération non A/B, le contenu de l'en-tête doit être autonome ; voir Images de récupération . Par exemple:
      • cmdline n'est pas concaténé à boot et vendor_boot cmdline .
      • L'en-tête spécifie la récupération DTBO, 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 . Par exemple:
      • cmdline est concaténé à boot et vendor_boot cmdline .
      • DTBO peut être déduit de l'en-tête vendor_boot .
    • image du disque virtuel recovery
      • Ressources de récupération
      • Pour les partitions de récupération non A/B, le contenu du disque virtuel doit être autonome ; voir Images de récupération . Par exemple:
      • lib/modules doit contenir tous les modules du noyau requis pour démarrer le mode de récupération
      • Le disque virtuel de récupération doit contenir init .
      • Pour la partition de récupération A/B, le disque virtuel de récupération est ajouté au début du disque virtuel générique et du disque vendor_boot , il n'a donc pas besoin d'être autonome. Par exemple:
      • lib/modules ne peut contenir que des modules de noyau supplémentaires requis pour démarrer le mode de récupération en plus des modules de noyau dans le disque virtuel vendor_boot .
      • Le lien symbolique sur /init peut exister, mais il est éclipsé par le binaire /init de première étape dans l'image de démarrage.

Contenu générique de l'image du disque virtuel

Le disque virtuel générique contient les composants suivants.

  • init
  • Ajout system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build des 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 construction contrôlent la manière 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 (ce qui est la valeur par défaut).

  • TARGET_NO_KERNEL . Cette variable indique si la build 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 le périphérique utilise l'image recovery comme image boot . Lors de l'utilisation de 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 ou PRODUCT_PACKAGES .

    Il s'agit du commutateur GKI au niveau de la carte ; toutes les variables répertoriées ci-dessous 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 virtuel sont créées sur vendor_boot .

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

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

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

    • Lorsqu'il est défini sur true , si BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

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

      • N'est pas défini, les clés GSI AVB sont créées dans $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb .

    • Lorsqu'il est vide, si BOARD_RECOVERY_AS_ROOT :

      • Est défini, les clés GSI AVB sont créées dans $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb .

      • N'est pas défini, les clés GSI AVB sont créées dans $ANDROID_PRODUCT_OUT/ramdisk/avb .

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE . Cette variable contrôle si l'image recovery contient ou non un noyau. Les appareils lancés avec Android 12 et utilisant la partition recovery A/B doivent définir cette variable sur true . Les appareils lancés avec Android 12 et utilisant 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 disque virtuel 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 la vbmeta chaînée.

Combinaisons autorisées

Composant ou variable Mise à niveau du périphérique sans partition recovery Mise à niveau du périphérique avec la partition recovery Lancer le périphérique sans partition recovery Lancer le périphérique avec la partition recovery A/B Lancer le périphérique avec une partition recovery non-A/B aosp_arm64
Contient boot Oui Oui Oui Oui Oui Oui
Contient init_boot (Android 13) Non Non Oui Oui Oui Oui
Contient vendor_boot facultatif facultatif Oui Oui Oui Non
Contient 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 dotés d'une partition recovery dédiée peuvent définir PRODUCT_BUILD_RECOVERY_IMAGE sur true ou vide. Pour ces appareils, si BOARD_RECOVERYIMAGE_PARTITION_SIZE est défini, une image recovery est créée.

Activer vbmeta chaîné 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 un exemple, reportez-vous à ce changement .

Système en tant que racine

Le système en tant que root n'est pas pris en charge pour 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 pris en charge pour les appareils qui utilisent des partitions dynamiques.

Configurations de produits

Les périphériques qui utilisent le disque virtuel générique doivent installer une liste de fichiers autorisés à être installés sur le disque virtuel. Pour ce faire, spécifiez ce qui suit dans device.mk :

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

Le fichier generic_ramdisk.mk empêche également d'autres makefiles d'installer accidentellement d'autres fichiers sur le disque virtuel (déplacez plutôt ces fichiers vers vendor_ramdisk ).

Configuration des appareils

Les instructions de configuration diffèrent entre les appareils lancés avec Android 13, la mise à niveau vers Android 12 et le lancement avec Android 12. Android 13 est configuré de la même manière qu'avec Android 12.

  • Appareils mis à niveau vers Android 12 :

    • Peut conserver la valeur de BOARD_USES_RECOVERY_AS_BOOT . S'ils le font, ils utilisent des configurations héritées et les nouvelles variables de build doivent être vides. Si de tels appareils :

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur true , l'architecture est celle illustrée dans la figure 3 .

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur vide, l'architecture est celle illustrée à la figure 4 .

    • Peut définir BOARD_USES_RECOVERY_AS_BOOT sur vide. S'ils le font, ils utilisent de nouvelles configurations. Si de tels 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 du périphérique est 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 du périphérique est l'option 2a ou l'option 2b .

  • Les appareils lancés avec Android 12 doivent configurer BOARD_USES_RECOVERY_AS_BOOT pour qu'il soit vide et utilise de nouvelles configurations. Si de tels 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 du périphérique est 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 du périphérique est l'option 2a ou l'option 2b .

Étant donné que aosp_arm64 construit uniquement GKI (et non vendor_boot ou recovery), ce n'est pas une cible complète. Pour les configurations de build aosp_arm64 , reportez-vous à generic_arm64 .

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

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

Définition des 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 virtuel vendor_boot peut contenir un lien symbolique /init vers /system/bin/init et init_second_stage.recovery dans /system/bin/init . Cependant, comme le disque virtuel générique est concaténé après le disque vendor_boot , le lien symbolique /init est écrasé. Lorsque le périphérique démarre en mode récupération, le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de la deuxième étape. Le contenu des disques virtuels vendor_boot + génériques est le suivant :

  • /init (à partir d'un disque virtuel générique, construit à partir de init_first_stage )
  • /system/bin/init (à partir de vendor_ramdisk , construit à partir de init_second_stage.recovery )

Déplacer des fichiers fstab

Déplacez tous les fichiers fstab installés sur le disque virtuel générique vers vendor_ramdisk . Pour un exemple, reportez-vous à ce changement .

Installation des modules

Si vous le souhaitez, vous pouvez installer des modules spécifiques au périphérique sur vendor_ramdisk (ignorez cette étape si vous n'avez aucun module spécifique au périphérique à installer).

  • Utilisez la variante vendor_ramdisk du module lorsque le module est installé sur /first_stage_ramdisk . Ce module devrait être disponible après que init ait basculé la racine vers /first_stage_ramdisk mais avant que init ne bascule la racine vers /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 devrait être disponible avant que init ne bascule root vers /first_stage_ramdisk . Pour plus de détails sur l'installation de modules sur / , voir Console de premier étage .

Console du premier étage

Étant donné que la console de première étape démarre avant que init ne bascule la racine vers /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 , donc si le makefile du périphérique 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 ce qui suit.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Cela garantit que l' linker , sh et toybox s'installent sur $ANDROID_PRODUCT_OUT/recovery/root/system/bin , qui s'installe ensuite sur /system/bin sous le vendor_ramdisk .

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

PRODUCT_PACKAGES += adbd.recovery

Cela garantit que les modules spécifiés s'installent sur $ANDROID_PRODUCT_OUT/recovery/root/system/bin , qui s'installe ensuite sur /system/bin sous le 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 prennent pas en charge GKI installent la variante de disque virtuel 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 un exemple, reportez-vous à cette liste de modifications .

Compression A/B virtuelle

Pour prendre en charge la compression A/B virtuelle, snapuserd doit être installé sur vendor_ramdisk . Le périphérique 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 sous Android ne change pas, à l'exception suivante :

  • Ramdisk build.prop se déplace dans /second_stage_resources afin que init de la deuxième étape puisse lire l'horodatage de construction du démarrage.

Étant donné que les ressources sont déplacées du disque virtuel générique vers le disque vendor_boot , le résultat de la concaténation du disque virtuel générique avec le disque virtuel vendor_boot ne change pas.

Rendre e2fsck disponible

Les makefiles de périphérique peuvent hériter de :

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk si l'appareil prend en charge l'A/B virtuel mais pas la compression.

  • virtual_ab_ota/compression.mk si l'appareil prend en charge la compression A/B virtuelle.

Les makefiles du produit installent $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck . Au moment de l'exécution, la première étape init bascule la racine vers /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 dotés de partitions recovery A/B ; c'est-à-dire que le périphérique possède une recovery_b partition recovery_a et recovery_b. Ces périphériques incluent les périphériques A/B et virtuels A/B dont la partition de récupération peut être mise à jour, avec la configuration suivante :

AB_OTA_PARTITIONS += recovery

Le disque virtuel vendor_boot contient les bits du fournisseur du disque virtuel et des modules du noyau du fournisseur, notamment les éléments suivants :

  • Fichiers fstab spécifiques au périphérique

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

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

Définition des valeurs BOARD

Définissez les valeurs suivantes pour les appareils dotés d'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 disque virtuel recovery peut contenir un lien symbolique /init -> /system/bin/init et init_second_stage.recovery à /system/bin/init . Cependant, comme le disque virtuel de démarrage est concaténé après le disque virtuel recovery , le lien symbolique /init est écrasé. Lorsque le périphérique démarre en mode de récupération, le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de la deuxième étape.

Lorsque le périphérique démarre en recovery , le contenu des disques virtuels recovery + vendor_boot + génériques est le suivant :

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

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

  • /init (à partir d'un disque virtuel générique, construit à partir de init_first_stage )

Déplacer des fichiers fstab

Déplacez tous les fichiers fstab installés sur le disque virtuel générique vers le vendor_ramdisk . Pour un exemple, reportez-vous à ce changement .

Installation des modules

Si vous le souhaitez, vous pouvez installer des modules spécifiques au périphérique sur vendor_ramdisk (ignorez cette étape si vous n'avez aucun module spécifique au périphérique à 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 étape , Sommes de contrôle des métadonnées et Compression A/B virtuelle .

Console du premier étage

Pour installer la variante vendor_ramdisk des modules, utilisez ce qui suit :

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Cela garantit que l' linker , sh et toybox s'installent sur $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , qui s'installe ensuite sur /system/bin sous le 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 téléchargeant les correctifs appropriés sur AOSP, puis utilisez ce qui suit :

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Cela garantit que les modules spécifiés sont installés sur $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin . Si le disque vendor_boot est chargé en mode de récupération, le module est également disponible en recovery . Si le disque vendor_boot n'est pas chargé en mode de récupération, le périphérique peut éventuellement installer adbd.recovery également.

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 prennent pas en charge GKI installent la variante de disque virtuel 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 un exemple, reportez-vous à cette liste de modifications .

Compression A/B virtuelle

Pour prendre en charge la compression Virtual A/B, snapuserd doit être installé sur vendor_ramdisk . Le périphérique 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 disque virtuel générique vendor_boot + est similaire au processus de démarrage existant, sauf que fstab se charge à partir de vendor_boot . Parce que system/bin/recovery n'existe pas, first_stage_init le gère comme un démarrage normal.

Lors du démarrage en mode de récupération, le processus de démarrage change. Le disque virtuel générique recovery + vendor_boot + est similaire 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 pour le mode de récupération est le suivant.

  1. Le chargeur de démarrage démarre, puis effectue les opérations suivantes :

    1. Pousse la récupération + vendor_boot + le disque virtuel générique vers / . (Si l'OEM duplique les modules du noyau dans le disque virtuel 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 virtuel sur / puis exécute /init à partir du disque virtuel générique.

  3. La première étape d'initialisation démarre, 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 le disque virtuel (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 disque virtuel recovery .

Rendre e2fsck disponible

Les makefiles de périphérique peuvent hériter de :

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk si l'appareil prend en charge l'A/B virtuel mais pas la compression.

  • virtual_ab_ota/compression.mk si l'appareil prend en charge la compression A/B virtuelle.

Les 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 non-A/B ; c'est-à-dire que le périphérique possède une partition nommée recovery sans suffixe d'emplacement. Ces appareils comprennent :

  • appareils non A/B ;
  • Périphériques A/B et Virtual A/B, dont la partition de récupération n'est pas mis à jour. (C'est inhabituel.)

Le disque virtuel vendor_boot contient les bits du fournisseur du disque virtuel et des modules du noyau du fournisseur, notamment les éléments suivants :

  • Fichiers fstab spécifiques au périphérique
  • 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 de récupération, notamment :

  • L'image du noyau
  • L’image DTBO
  • Modules du noyau dans lib/modules
  • Init de 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 au périphérique
  • Toutes les autres ressources de récupération, y compris le binaire recovery , etc.
  • etc.

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

Définition des 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 virtuel recovery doit contenir un lien symbolique /init -> /system/bin/init et init_second_stage.recovery à /system/bin/init . Lorsque le périphérique démarre en mode de 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 en recovery , le contenu des disques virtuels recovery est le suivant :

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

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

  • /init (à partir du disque virtuel, construit à partir de init_first_stage )

Déplacer des fichiers fstab

Déplacez tous les fichiers fstab installés sur le disque virtuel générique vers le vendor_ramdisk et le disque virtuel recovery . Pour un exemple, reportez-vous à ce changement .

Installation des modules

Si vous le souhaitez, vous pouvez installer des modules spécifiques au périphérique sur vendor_ramdisk et le disque virtuel recovery (ignorez cette étape si vous n'avez aucun module spécifique au périphérique à installer). init ne change pas de root. La variante vendor_ramdisk des modules s'installe à la racine de vendor_ramdisk . La variante recovery des modules s'installe à la racine du disque virtuel recovery . Pour des exemples d'installation de modules sur vendor_ramdisk et le disque virtuel recovery , voir Console de premier étage et sommes de contrôle des métadonnées .

Console du premier étage

Pour installer la variante vendor_ramdisk des modules, utilisez ce qui suit :

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Cela garantit que l' linker , sh et toybox s'installent sur $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , qui s'installe ensuite sur /system/bin sous le 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 téléchargeant les correctifs appropriés sur AOSP, puis utilisez ce qui suit :

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Cela garantit que les modules spécifiés sont installés sur $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 prennent pas en charge GKI installent la variante de disque virtuel 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 lors 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

Lors du démarrage sous Android, le processus de démarrage ne change pas. Le disque virtuel générique vendor_boot + est similaire au processus de démarrage existant, sauf que fstab se charge à partir de vendor_boot . Parce que system/bin/recovery n'existe pas, first_stage_init le gère comme un démarrage normal.

Lors du démarrage en mode de récupération, le processus de démarrage ne change pas. Le disque virtuel 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 pour le mode de récupération est le suivant.

  1. Le chargeur de démarrage démarre, puis effectue les opérations suivantes :

    1. Pousse le disque virtuel de récupération vers / .
    2. Exécute le noyau à partir de la partition recovery .

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

  3. La première étape d'initialisation démarre, 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 le disque virtuel (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 disque virtuel recovery .

Horodatages des images 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 construction, un fichier system/etc/ramdisk/build.prop est ajouté au disque virtuel générique. Ce fichier contient des informations d'horodatage de la build.

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