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 disque virtuel générique est supprimé de l'image boot et placé dans une image init_boot distincte. Cette modification laisse l'image boot avec uniquement le noyau GKI.

Pour la mise à niveau des appareils qui continuent d'utiliser Android 12 ou des versions de noyau plus anciennes, le disque virtuel générique reste là où il était sans qu'une nouvelle image init_boot soit requise.

Pour créer un disque virtuel générique, déplacez les ressources spécifiques au fournisseur hors du disque virtuel de 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 restauration sont déplacés du ramdisk générique vers le ramdisk vendor_boot .

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

Architecture

Les schémas suivants illustrent l'architecture des appareils exécutant Android 12 et versions ultérieures. Le lancement de l'appareil avec Android 13 a une nouvelle image init_boot contenant le ramdisk 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 recovery dédié

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

Figure 1. Appareils lançant ou passant à 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é)

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

Figure 2. Appareils lançant ou passant à 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, restauration dédiée et non A/B (disque virtuel dédié)

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

Figure 3. Appareils lançant ou passant à Android 13, avec GKI, récupération dédiée et non-A/B

Reportez-vous à cette figure si le périphérique possède une partition nommée recovery sans suffixe d'emplacement.

Lancer ou mettre à 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 lançant ou passant à 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é)

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

Figure 5. Appareils lançant ou passant à 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 .

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

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

Figure 6. Appareils lançant ou passant à Android 12, avec GKI, restauration dédiée et non-A/B

Reportez-vous à cette figure si le périphérique possède 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 RAM)

Lancer/mettre à niveau 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 au démarrage

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

Dispositif 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 à l'appareil.
      • 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 RAM vendor_boot
      • lib/modules
      • Ressources de restauration (si aucune restauration dédiée)
    • image dtb

  • image recovery

    • Version d'en-tête V2
      • 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 ; voir Images de récupération . Par exemple:
      • cmdline n'est pas concaténé avec 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 . Par exemple:
      • cmdline est concaténé avec boot et vendor_boot cmdline .
      • DTBO peut être déduit de l'en-tête vendor_boot .
    • image de disque RAM recovery
      • Ressources de récupération
      • Pour une partition de restauration 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 RAM de récupération doit contenir init .
      • Pour la partition de restauration A/B, le ramdisk de restauration est ajouté au générique et au ramdisk vendor_boot , il n'a donc pas besoin d'être autonome. Par exemple:
      • lib/modules peut contenir uniquement des modules de noyau supplémentaires requis pour démarrer le mode de récupération en plus des modules de noyau dans le ramdisk vendor_boot .
      • Le lien symbolique à /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 ramdisk 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 façon dont les images init_boot , boot , recovery et vendor_boot sont construites. La valeur d'une variable de tableau booléenne 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 construction 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 listé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 de disque virtuel sont créées pour vendor_boot .

    • Lorsqu'il est défini sur true , les ressources de récupération sont créées uniquement sur vendor-ramdisk/ et ne sont pas créées sur 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 GSI AVB sont construites pour 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 construites sur $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb .

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

    • Lorsqu'il est vide, si BOARD_RECOVERY_AS_ROOT :

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

      • N'est pas défini, les clés GSI AVB sont construites sur $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 qui se lancent 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/ 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 vbmeta chaîné

Combinaisons autorisées

Composant ou variable Mise à niveau de l'appareil sans partition recovery Mise à niveau de l'appareil avec partition recovery Lancer l'appareil sans partition recovery Lancer l'appareil avec la partition recovery A/B Lancer un 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

vbmeta chaîné doit être activé pour les images boot et init_boot . Spécifiez ce qui suit :

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 à cette modification .

Système en tant que racine

Le système en tant que racine n'est pas pris en charge pour les appareils qui utilisent GKI. Sur de tels 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 du produit

Les périphériques 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 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 ramdisk (déplacez ces fichiers vers vendor_ramdisk à la place).

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

  • Mise à niveau des appareils 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 construction doivent être vides. Si ces appareils :

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur true , l'architecture est comme illustré à la figure 3 .

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur vide, l'architecture est comme illustré Figure 4 .

    • Peut 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 celle illustrée à la figure 1 et l'option de configuration du périphérique est l'option 1 .

      • Utilisez une partition recovery dédiée, l'architecture est telle qu'illustrée à 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 définir BOARD_USES_RECOVERY_AS_BOOT sur vide et utiliser de nouvelles configurations. Si ces appareils :

    • N'utilisez pas de partition recovery dédiée, l'architecture est celle illustrée à la figure 1 et l'option de configuration du périphérique est l'option 1 .

    • Utilisez une partition recovery dédiée, l'architecture est telle qu'illustrée à 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 ne construit que 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 : Aucune 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 ramdisk 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 .

Réglage 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 ramdisk vendor_boot peut contenir un lien symbolique /init vers /system/bin/init et init_second_stage.recovery sur /system/bin/init . Cependant, 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 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 disque virtuel générique, construit à partir de init_first_stage )
  • /system/bin/init (de vendor_ramdisk , construit à 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 un exemple, reportez-vous à cette modification .

Installation 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 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 devrait être disponible après que init bascule la racine dans /first_stage_ramdisk mais avant init bascule la racine dans /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 s'installe sur / . Ce module devrait être disponible avant que init ne bascule la racine dans /first_stage_ramdisk . Pour plus de détails sur l'installation des modules dans / , voir Console de premier niveau .

Console du premier étage

Étant donné que la console de 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 sur build/make/target/product/base_vendor.mk , donc 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 ce qui suit.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Cela garantit que l' linker , sh et toybox sont installés 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 premier niveau (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 RAM 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 du processus de démarrage

Le processus de démarrage en récupération ou sur Android ne change pas, à l'exception suivante :

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

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

Rendre e2fsck disponible

Les makefiles de l'appareil peuvent hériter de :

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk si le périphérique prend en charge l'A/B virtuel mais pas la compression.

  • virtual_ab_ota/compression.mk si le périphérique prend en charge la compression virtuelle A/B.

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 dans /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 périphériques avec des partitions recovery A/B ; c'est-à-dire que le périphérique a une partition recovery_a et recovery_b partition . Ces périphériques incluent les périphériques A/B et Virtual A/B 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 vendeur des modules du ramdisk et du noyau du vendeur, y compris les éléments suivants :

  • Fichiers fstab spécifiques à l'appareil

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

Le disque RAM recovery contient toutes les ressources de restauration. Sur ces appareils, la configuration du produit hérite de generic_ramdisk.mk .

Réglage des valeurs BOARD

Définissez les valeurs suivantes pour les appareils avec 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, étant donné que le disque virtuel de démarrage est concaténé après le disque virtuel recovery , le lien symbolique /init est écrasé. Lorsque l'appareil démarre en mode de récupération, le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de deuxième étape.

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

  • /init (à partir du disque virtuel, construit à partir de init_first_stage )
  • /system/bin/init (à partir du disque RAM recovery , construit à 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 disque virtuel générique, construit à 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 le vendor_ramdisk . Pour un exemple, reportez-vous à cette modification .

Installation 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 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 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 le 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 pertinents sur AOSP, puis utilisez ce qui suit,

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 en recovery . Si le ramdisk vendor_boot n'est pas chargé en mode de récupération, l'appareil peut éventuellement installer également 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 RAM 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 du processus de démarrage

Lors du démarrage sur Android, le processus de démarrage ne change pas. Le vendor_boot + ramdisk générique est similaire au processus de démarrage existant, sauf que fstab se charge à partir de vendor_boot . Étant donné 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 recovery + vendor_boot + ramdisk générique 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. Bootloader démarre, puis effectue les opérations suivantes :

    1. Pousse recovery + vendor_boot + ramdisk générique vers / . (Si l'OEM duplique les modules du noyau dans le disque RAM 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. L'initialisation de la première étape 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 . (Le périphérique 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 RAM recovery .

Rendre e2fsck disponible

Les makefiles de l'appareil peuvent hériter de :

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk si le périphérique prend en charge l'A/B virtuel mais pas la compression.

  • virtual_ab_ota/compression.mk si le périphérique prend en charge la compression virtuelle A/B.

Les makefiles 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 périphériques avec 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 dispositifs comprennent :

  • appareils non A/B ;
  • Périphériques A/B et Virtual A/B, dont la partition de restauration n'est pas modifiable. (C'est inhabituel.)

Le ramdisk vendor_boot contient les bits du vendeur des modules du ramdisk et du noyau du vendeur, 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 de récupération, notamment :

  • L'image du noyau
  • L'image DTBO
  • Modules du noyau dans lib/modules
  • Init de première étape sous forme de 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 , etc.
  • etc.

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

Réglage 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 dans /system/bin/init . Lorsque l'appareil démarre en mode de récupération, le binaire /system/bin/init est nécessaire pour prendre en charge à la fois l'initialisation de la première et de la deuxième étape.

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

  • /init -> /system/bin/init (à partir du disque RAM recovery )
  • /system/bin/init (à partir du disque RAM recovery , construit à 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 disque virtuel, construit à 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 le vendor_ramdisk et le ramdisk recovery . Pour un exemple, reportez-vous à cette modification .

Installation des modules

Si vous le souhaitez, vous pouvez installer des modules spécifiques à l'appareil sur vendor_ramdisk et recovery 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 . La variante recovery des modules s'installe à la racine du disque RAM recovery . Pour des exemples d'installation de modules sur vendor_ramdisk et recovery ramdisk, voir First stage console et Metadata checksums .

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 le 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 pertinents sur AOSP, puis utilisez ce qui suit,

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 prennent pas en charge GKI installent la variante de disque RAM 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 de la récupération, activez la variante de récupération de ces modules et installez-les également.

Modifications du processus de démarrage

Lors du démarrage sur Android, le processus de démarrage ne change pas. Le vendor_boot + ramdisk générique est similaire au processus de démarrage existant, sauf que fstab se charge à partir de vendor_boot . Étant donné 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 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 pour le mode de récupération est le suivant.

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

    1. Pousse le disque RAM 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. L'initialisation de la première étape 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 . (Le périphérique 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 RAM recovery .

Horodatage 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 ramdisk générique. Ce fichier contient des informations d'horodatage de la construction.

  • Lors 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 .