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 virtuelvendor_boot
.Utilisez une partition
recovery
dédiée, aucune modification du disque virtuelrecovery
n'est nécessaire car le disque virtuelrecovery
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
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é)
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é)
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
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é)
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é)
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)
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é)
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). Leboot.img
GKI certifié n'est pas signé pour un démarrage vérifié. Les OEM doivent toujours signer leboot.img
prédéfini avec une clé AVB spécifique au périphérique. -
cmdline
générique (GENERIC_KERNEL_CMDLINE
) - Noyau GKI
- Une
- Image de disque virtuel générique
- Inclus uniquement dans les images
boot
d'Android 12 et versions antérieures
- Inclus uniquement dans les images
- Version d'en-tête V3 ou V4
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
- en-tête
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
etvendor_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
etvendor_boot
. Par exemple: -
cmdline
est concaténé àboot
etvendor_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 virtuelvendor_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.
- En-tête version V2
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/
- Répertoires vides dupliqués pour les points de montage :
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 surtrue
, définissezBOARD_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'imagerecovery
comme imageboot
. Lors de l'utilisation de GKI, cette variable est vide et les ressources de récupération doivent être déplacées versvendor_boot
.BOARD_USES_GENERIC_KERNEL_IMAGE
. Cette variable indique que la carte utilise GKI. Cette variable n'affecte pas sysprops ouPRODUCT_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 survendor_boot
.Lorsqu'elles sont définies sur
true
, les ressources de récupération sont créées uniquement survendor-ramdisk/
et non surrecovery/root/
.Lorsqu'elles sont vides, les ressources de récupération sont créées uniquement dans
recovery/root/
et non dansvendor-ramdisk/
.
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT
. Cette variable contrôle si les clés GSI AVB sont créées survendor_boot
.Lorsqu'il est défini sur
true
, siBOARD_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'imagerecovery
contient ou non un noyau. Les appareils lancés avec Android 12 et utilisant la partitionrecovery
A/B doivent définir cette variable surtrue
. Les appareils lancés avec Android 12 et utilisant non-A/B doivent définir cette variable surfalse
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é dansIMAGES/
sous les fichiers cibles.aosp_arm64
doit définir cette variable surtrue
.Les autres appareils doivent laisser cette variable vide.
BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE
. Cette variable contrôle siinit_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 deboot.img
et nécessite que les variablesBOARD_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
surtrue
, 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
Init binaires et liens symboliques
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 deinit_first_stage
) -
/system/bin/init
(à partir devendor_ramdisk
, construit à partir deinit_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 queinit
ait basculé la racine vers/first_stage_ramdisk
mais avant queinit
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 queinit
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 queinit
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ériquelib/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
Init binaires et liens symboliques
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 deinit_first_stage
) -
/system/bin/init
(à partir du disque virtuelrecovery
, construit à partir deinit_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 deinit_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.
Le chargeur de démarrage démarre, puis effectue les opérations suivantes :
- 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.) - Exécute le noyau à partir de la partition
boot
.
- Pousse la récupération +
Le noyau monte le disque virtuel sur
/
puis exécute/init
à partir du disque virtuel générique.La première étape d'initialisation démarre, puis effectue les opérations suivantes :
- Définit
IsRecoveryMode() == true
etForceNormalBoot() == false
. - Charge les modules du noyau du fournisseur à partir de
/lib/modules
. - Appelle
DoFirstStageMount()
mais ignore le montage carIsRecoveryMode() == true
. (L'appareil ne libère pas le disque virtuel (car/
est toujours le même) mais appelleSetInitAvbVersionInRecovery()
.) - Démarre l'initialisation de la deuxième étape à partir de
/system/bin/init
à partir du disque virtuelrecovery
.
- Définit
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
Init binaires et liens symboliques
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 virtuelrecovery
) -
/system/bin/init
(à partir du disque virtuelrecovery
, construit à partir deinit_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 deinit_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.
Le chargeur de démarrage démarre, puis effectue les opérations suivantes :
- Pousse le disque virtuel de récupération vers
/
. - Exécute le noyau à partir de la partition
recovery
.
- Pousse le disque virtuel de récupération vers
Le noyau monte le disque virtuel sur
/
puis exécute/init
, qui est un lien symbolique vers/system/bin/init
à partir du disque virtuelrecovery
.La première étape d'initialisation démarre, puis effectue les opérations suivantes :
- Définit
IsRecoveryMode() == true
etForceNormalBoot() == false
. - Charge les modules du noyau du fournisseur à partir de
/lib/modules
. - Appelle
DoFirstStageMount()
mais ignore le montage carIsRecoveryMode() == true
. (L'appareil ne libère pas le disque virtuel (car/
est toujours le même) mais appelleSetInitAvbVersionInRecovery()
.) - Démarre l'initialisation de la deuxième étape à partir de
/system/bin/init
à partir du disque virtuelrecovery
.
- Définit
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 verstmpfs
avant de libérer le disque virtuel afin queinit
de la deuxième étape puisse lire ce fichier pour définir les propriétés d'horodatage de l'imageboot
.