Partition de démarrage générique

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

Pour les appareils équipés d'Android 13, ramdisk est supprimé de l'image boot et placé dans un autre init_boot l'image. Cette modification ne conserve que l'élémentboot noyau GKI.

Pour mettre à niveau les appareils qui continuent à utiliser Android 12 ou des versions de noyau plus anciennes, le ramdisk générique reste à sa place avec aucune nouvelle image init_boot n'est nécessaire.

Pour créer un ramdisk générique, retirez les ressources spécifiques aux fournisseurs de sorte que le ramdisk générique ne contienne que la première étape init et une propriété contenant des informations de code temporel.

Sur les appareils qui:

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

  • Utilisez une partition recovery dédiée, sans modifier le ramdisk recovery. est nécessaire, car le ramdisk recovery est autonome.

Architecture

Les schémas suivants illustrent l'architecture pour les appareils exécutant Android 12 et versions ultérieures. Les appareils équipés d'Android 13 disposent d'une nouvelle Image init_boot contenant le ramdisk générique. Appareils passant d'Android 12 à Android 13 utilisent la même architecture Android 12.

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

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

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

Lancez votre application avec Android 13, un service dédié et la récupération A/B (ramdisk dédié).

Lancer/Mettre à niveau l'appareil, l'outil GKI, la récupération dédiée et la récupération A/B

Figure 2. Appareils lancés ou passant à 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.

Lancez-vous avec Android 13, avec la récupération dédiée et non A/B (ramdisk dédié)

Lancer/Mettre à niveau l'appareil, GKI, récupération dédiée et non A/B

Figure 3. Appareils lancés ou passant à Android 13, avec GKI, récupération dédiée et autre que A/B

Reportez-vous à la figure suivante si l'appareil a une partition nommée recovery sans 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

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

Lancer/Mettre à niveau l'appareil, l'outil GKI, la récupération dédiée et la récupération A/B

Figure 5. Appareils lancés ou passant à 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.

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

Lancer/Mettre à niveau l'appareil, GKI, récupération dédiée et non A/B

Figure 6. Appareils lancés ou passant à Android 12, avec GKI, récupération dédiée et autre que A/B

Reportez-vous à la figure suivante si l'appareil a une partition nommée recovery sans d'emplacement.

Passer à Android 12, Recovery as Boot (recovery as-ramdisk)

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

Figure 7. Appareils passant à Android 12, sans GKI, avec récupération au démarrage

Passer à Android 12, récupération dédiée (ramdisk dédié)

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

Figure 8. Appareils passant à 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 ramdisk générique

  • Image générique boot

    • Version d'en-tête V3 ou V4 <ph type="x-smartling-placeholder">
        </ph>
      • boot_signature pour la certification GKI boot.img (v4 uniquement). La certifié GKI boot.img n'est pas signé pour le démarrage validé. Les OEM doivent toujours signer le boot.img prédéfini avec un code spécifique à l'appareil AVB .
      • Générique cmdline (GENERIC_KERNEL_CMDLINE)
      • Noyau GKI
    • Image ramdisk générique <ph type="x-smartling-placeholder">
        </ph>
      • Inclus uniquement dans les images boot d'Android 12 et avant

  • Image vendor_boot (pour en savoir plus, consultez Démarrage fournisseur Partitions)

    • En-tête vendor_boot <ph type="x-smartling-placeholder">
        </ph>
      • cmdline spécifique à l'appareil (BOARD_KERNEL_CMDLINE)
    • Image ramdisk vendor_boot <ph type="x-smartling-placeholder">
        </ph>
      • lib/modules
      • Ressources de récupération (en l'absence de ressources dédiées)
    • Image dtb

  • Image recovery

    • Version 2 d'en-tête <ph type="x-smartling-placeholder">
        </ph>
      • cmdline spécifique à l'appareil pour la récupération, si nécessaire
      • Dans le cas d'une partition de récupération autre que A/B, le contenu de l'en-tête doit être autonome ; voir Images de récupération. Exemple :
      • cmdline n'est pas concaténé avec boot et vendor_boot cmdline.
      • L'en-tête indique le DTBO de récupération, si nécessaire.
      • Pour la partition de récupération A/B, le contenu peut être concaténé ou déduit de boot et vendor_boot. Exemple :
      • cmdline est concaténé avec boot et vendor_boot cmdline.
      • Le DTBO peut être déduit à partir de l'en-tête vendor_boot.
    • Image ramdisk recovery <ph type="x-smartling-placeholder">
        </ph>
      • Ressources de récupération
      • Dans le cas d'une partition de récupération autre que A/B, le contenu du disque RAM autonome ; voir Images de récupération. Exemple :
      • lib/modules doit contenir tous les modules du noyau nécessaires au démarrage mode Recovery
      • Le disque RAM de récupération doit contenir init.
      • Pour la partition de récupération A/B, le préfixe ramdisk est ajouté au début et vendor_boot ramdisk, et n'a donc pas besoin d'être autonome. Exemple :
      • lib/modules peut ne contenir que les modules de noyau supplémentaires requis pour mode récupération au démarrage en plus des modules du noyau dans vendor_boot ramdisk.
      • Le lien symbolique sur /init existe peut-être, mais il est éclipsé par le le binaire /init de première étape dans l'image de démarrage.

Contenu de l'image ramdisk générique

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

  • init
  • system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build accessoires
  • Répertoires vides pour les points 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/ et metadata/

Intégration de l'image de démarrage

Les options de compilation contrôlent la manière dont init_boot, boot, recovery et vendor_boot des images sont créées. La valeur d'une variable de tableau booléenne doit être la chaîne true ou être vide (valeur par défaut).

  • TARGET_NO_KERNEL Cette variable indique si la compilation utilise un système de démarrage l'image. Si cette variable est définie sur true, définissez BOARD_PREBUILT_BOOTIMAGE. à 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 en tant qu'image boot. Lorsque vous utilisez GKI, cette variable est et les ressources de récupération doivent être déplacées vers vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE Cette variable indique que le tableau utilise GKI. Cette variable n'affecte pas sysprops ni PRODUCT_PACKAGES

    Il s'agit du commutateur GKI au niveau du tableau ; toutes les variables suivantes restreint par cette variable.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT Cette variable détermine si Les ressources de récupération ramdisk sont conçues pour vendor_boot.

    • Lorsque ce paramètre est défini sur true, les ressources de récupération sont conçues pour vendor-ramdisk/ uniquement et ne sont pas conçus pour recovery/root/.

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

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT Cette variable contrôle si les GSI Les clés AVB sont conçues pour vendor_boot.

    • Si défini sur true, si BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • sont définies, les clés AVB GSI sont conçues $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb

      • n'est pas définie, les clés AVB GSI sont conçues $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb

    • Lorsque ce champ est vide, si la valeur est BOARD_RECOVERY_AS_ROOT:

      • sont définies, les clés AVB GSI sont conçues $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb

      • n'est pas définie, les clés AVB GSI sont conçues $ANDROID_PRODUCT_OUT/ramdisk/avb

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE Cette variable détermine si le L'image recovery contient ou non un noyau. Appareils équipés d'Android 12 et l'utilisation de la partition A/B recovery doit définir ce sur true. Appareils équipés d'Android 12 Si vous utilisez une valeur autre que A/B, vous devez définir cette variable sur false pour conserver l'image de récupération autonome.

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

    • aosp_arm64 doit définir cette variable sur true.

    • Pour les autres appareils, vous devez laisser cette variable vide.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE Cette variable détermine si init_boot.img est généré et définit la taille. Une fois défini, le disque générique ramdisk est ajouté à init_boot.img à la place de boot.img et nécessite que le Variables BOARD_AVB_INIT_BOOT* à définir pour vbmeta enchaîné.

Combinaisons autorisées

Composant ou variable Mettre à niveau l'appareil sans partition de récupération Mettre à niveau l'appareil avec la 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 que 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 &gt; 0 vide &gt; 0 &gt; 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 à true ou 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. Préciser 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 consulter un exemple, reportez-vous à ce document modification.

Système en tant que racine

Le système en tant que racine n'est pas compatible avec les appareils qui utilisent GKI. Activé ces appareils, BOARD_BUILD_SYSTEM_ROOT_IMAGE doit être vide. 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 peut être installé sur le ramdisk. Pour ce faire, spécifiez les éléments suivants dans device.mk:

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

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

Configurer des appareils

Les instructions de configuration varient d'un appareil à l'autre avec Android. 13, passer à Android 12 et lancer avec Android 12. Android 13 sont configurés de la même manière qu'avec Android 12.

  • Appareils passant à Android 12:

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

      • Définissez BOARD_USES_RECOVERY_AS_BOOT sur true. L'architecture se présente comme suit : comme indiqué dans la Figure 3.

      • Laissez BOARD_USES_RECOVERY_AS_BOOT vide. L'architecture se présente comme suit. Figure 4 :

    • Vous pouvez définir BOARD_USES_RECOVERY_AS_BOOT sur vide. Si c'est le cas, elle utilise de nouvelles configurations. Si ces appareils:

      • N'utilisez pas de partition recovery dédiée, l'architecture est telle qu'elle est indiquée. de la Figure 1 et que l'option de configuration de l'appareil est Option 1.

      • Utilisez une partition recovery dédiée. L'architecture se présente comme dans l'exemple Figure 2a ou Figure 2b et configuration de l'appareil est Option 2a ou Option 2b.

  • Pour les appareils équipés d'Android 12, BOARD_USES_RECOVERY_AS_BOOT doit être vide et utiliser de nouvelles configurations. Si tel appareils:

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

    • Utilisez une partition recovery dédiée. L'architecture se présente comme dans l'exemple Figure 2a ou Figure 2b et configuration de l'appareil est Option 2a ou Option 2b.

Comme aosp_arm64 crée uniquement GKI (et non vendor_boot ou la récupération), il n'est pas un objectif complet. Pour les aosp_arm64configurations de compilation, consultez generic_arm64

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

Les appareils sans partition recovery contiennent l'image générique boot 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, le la configuration du produit hérite de generic_ramdisk.mk

Définir les valeurs du tableau

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 de /init à /system/bin/init, et init_second_stage.recovery à /system/bin/init. Toutefois, comme le Le disque ramdisk générique est concaténé après vendor_boot, et /init le lien symbolique est écrasé. Lorsque l'appareil démarre en cours de récupération, Le binaire /system/bin/init est nécessaire pour prendre en charge l'initialisation de la deuxième étape. Contenu de vendor_boot + les disques RAM génériques se présentent comme suit:

  • /init (à partir de 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 sur le disque ramdisk générique vers vendor_ramdisk Pour consulter un exemple, reportez-vous à ce document modification.

Installer des modules

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

  • Utilisez la variante vendor_ramdisk du module lorsqu'il s'installe dans /first_stage_ramdisk. Ce module devrait être disponible après le init remplace la racine en /first_stage_ramdisk, mais avant init, passe à la racine en /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 celui-ci s'installe dans /. Ce module doit être disponible avant que init ne bascule en racine /first_stage_ramdisk Pour en savoir plus sur l'installation de modules dans /, consultez la section la console de préproduction.

Console de premier niveau

Comme la première console démarre avant que init ne passe en mode root /first_stage_ramdisk, vous devez installer la variante de modules recovery. Par défaut, les deux variantes de module sont installées build/make/target/product/base_vendor.mk : si le fichier makefile de l'appareil hérite À partir de ce fichier, vous n'avez pas besoin d'installer explicitement la variante recovery.

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

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Cela garantit que linker, sh et toybox sont installés 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 premier niveau (par exemple, adbd), utilisez la classe suivis.

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 sur /system/bin sous vendor_ramdisk.

Sommes de contrôle des métadonnées

Pour accepter les métadonnées de contrôle Lors de l'installation initiale, les périphériques non compatibles avec GKI installent variante 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 consulter un exemple, reportez-vous à ce document liste des modifications.

Compression virtuelle A/B

Pour prendre en charge la compression A/B virtuelle, snapuserd doit être installé sur vendor_ramdisk L'appareil doit hériter des 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 Android ne change pas, exception suivante:

  • Le disque RAM build.prop passe à /second_stage_resources, ce qui permet de passer à la deuxième étape init peut lire l'horodatage de la compilation du démarrage.

Comme les ressources passent d'un disque ramdisk générique à un disque ramdisk vendor_boot, le résultat de la concaténation du ramdisk générique avec le ramdisk vendor_boot ne change pas.

Rendre e2fsck disponible

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

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

  • virtual_ab_ota/compression.mk si l'appareil est compatible avec les fonctionnalités virtuelles A/B. la compression.

Les fichiers makefile du produit s'installent $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck À l'environnement d'exécution, la première étape init passe à la racine /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 l'appareil dispose d'un recovery_a et d'un recovery_b partition. Il s'agit par exemple des appareils suivants : Périphériques A/B et virtuels A/B virtuels pour lesquels 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 de fournisseur du ramdisk et le fournisseur du noyau, y compris les suivants:

  • Fichiers fstab spécifiques à l'appareil

  • lib/modules (inclut les modules de noyau des fournisseurs)

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

Définir les valeurs du tableau

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

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

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

Lorsque l'appareil démarre dans recovery, le contenu de recovery + Les disques vendor_boot et les disques RAM génériques se présentent comme suit:

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

Lorsque l'appareil démarre sous Android, le contenu de vendor_boot + le mot clé générique Les disques RAM sont les suivants:

  • /init (à partir de 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 le vendor_ramdisk Pour consulter un exemple, reportez-vous à ce document modification.

Installer des modules

Vous pouvez éventuellement installer des modules spécifiques à l'appareil pour vendor_ramdisk (ignorer cette étape si vous n'avez pas à installer de modules spécifiques à l'appareil). Init ne change pas de racine. La variante vendor_ramdisk des modules s'installe dans racine de vendor_ramdisk. Pour obtenir des exemples d'installation de modules dans vendor_ramdisk, consultez la section Console de première étape, Métadonnées sommes de contrôle et Virtual A/B la compression.

Console de premier niveau

Pour installer la variante vendor_ramdisk des modules, utilisez le code suivant:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Cela garantit que linker, sh et toybox sont installés 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 premier niveau (par exemple, adbd), activez la variante vendor_ramdisk de ces modules en important les correctifs pertinents AOSP, puis utilisez ce qui suit :

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Cela garantit 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 vendor_boot RAMdisk n'est pas chargée en mode récupération, l'appareil peut éventuellement installer adbd.recovery également.

Sommes de contrôle des métadonnées

Pour accepter les métadonnées de contrôle Lors de l'installation initiale, les périphériques non compatibles avec GKI installent variante 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 consulter un exemple, reportez-vous à ce document liste des modifications.

Compression virtuelle A/B

Pour prendre en charge la compression A/B virtuelle, snapuserd doit être installé sur vendor_ramdisk L'appareil doit hériter des 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. L'option vendor_boot + Le disque ramdisk générique est semblable au processus de démarrage existant, sauf que fstab les chargements depuis 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 Recovery, le processus de démarrage change. La récupération + 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 du mode Recovery est le suivant.

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

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

  2. Le noyau installe ramdisk sur /, puis exécute /init à partir de ramdisk générique.

  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 ramdisk, car / est identique), mais appelle SetInitAvbVersionInRecovery().)
    4. Démarre la deuxième étape de l'initialisation à partir de /system/bin/init depuis recovery ramdisk.

Rendre e2fsck disponible

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

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

  • virtual_ab_ota/compression.mk si l'appareil est compatible avec les fonctionnalités virtuelles A/B. la compression.

Les fichiers makefile du produit s'installent $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck À 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. c'est-à-dire l'appareil comporte une partition nommée recovery sans suffixe d'emplacement. De tels appareils incluent:

  • les appareils non-A/B ;
  • Appareils A/B et virtuels A/B, dont la partition de récupération n'est pas peuvent être mises à jour. (C'est inhabituel.)

Le ramdisk vendor_boot contient les bits de fournisseur du ramdisk et le fournisseur du noyau, y compris les 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:

  • L'image du noyau
  • Image DTBO
  • Modules du noyau dans lib/modules
  • Initialisation de la première étape en tant que lien symbolique /init -> /system/bin/init
  • Binaire d'initialisation /system/bin/init de deuxième étape
  • 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 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 ramdisk recovery doit contenir un lien symbolique /init -> /system/bin/init. 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 entre les deux étapes.

Lorsque l'appareil démarre dans recovery, le contenu des disques RAM recovery est comme suit:

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

Lorsque l'appareil démarre sous Android, le contenu de vendor_boot + le mot clé générique Les disques RAM sont les suivants:

  • /init (à partir de ramdisk, 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 le vendor_ramdisk et recovery. Pour consulter un exemple, reportez-vous à ce document modification.

Installer des modules

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

Console de premier niveau

Pour installer la variante vendor_ramdisk des modules, utilisez le code suivant:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Cela garantit que linker, sh et toybox sont installés 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 premier niveau (par exemple, adbd), activez la variante vendor_ramdisk de ces modules en important les correctifs pertinents AOSP, puis utilisez ce qui suit :

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Cela garantit 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 accepter les métadonnées de contrôle Lors de l'installation initiale, les périphériques non compatibles avec GKI installent variante 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 de les installer également.

Modifications apportées au processus de démarrage

Lors du démarrage sous Android, le processus de démarrage ne change pas. L'option vendor_boot + Le disque ramdisk générique est semblable au processus de démarrage existant, sauf que fstab les chargements depuis 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. La récupération ramdisk 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. La le processus de démarrage du mode Recovery :

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

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

  2. Le noyau installe 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 ramdisk, car / est identique), mais appelle SetInitAvbVersionInRecovery().)
    4. Démarre la deuxième étape de l'initialisation à partir de /system/bin/init depuis recovery ramdisk.

Codes temporels 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 compilation, un fichier system/etc/ramdisk/build.prop est ajouté au répertoire générique "ramdisk". Ce fichier contient les informations de code temporel de la compilation.

  • Lors de l'exécution, première étape init copies du disque ramdisk à tmpfs avant de libérer celui-ci pour que ce second l'étape init peut lire ce fichier pour définir les propriétés d'horodatage boot de l'image.