Depuis Android 10, l' image système générique (GSI) utilisée pour exécuter les tests de conformité CTS-on-GSI/VTS est passée de userdebug au type de build utilisateur afin d'être signée. Il s'agit d'un problème pour les tests VTS, car VTS nécessite l'exécution adb root
, mais adb root
n'est pas disponible sur un appareil de build utilisateur.
Le disque virtuel de débogage (ou image de démarrage de débogage) est introduit pour activer adb root
sur un périphérique de build utilisateur dont le chargeur de démarrage est déverrouillé . Cela simplifie le flux de test en utilisant le même système GSI system.img
créé par l'utilisateur pour CTS-on-GSI et VTS-on-GSI. Pour la configuration STS, l’utilisation d’un autre system.img
OEM userdebug.img est toujours requise.
Le tableau suivant présente les modifications apportées aux images et aux types de build pour les tests de conformité dans Android 10.
Suite de tests | Testez avec | Construire | Déboguer le disque virtuel | racine adb ? | Modification de la variante de build Android 9 -> 10 |
---|---|---|---|---|---|
CTS | Système OEM | utilisateur | N | N | Pas de changement |
CTS-sur-GSI | GSI | utilisateur | N | N | userdebug -> utilisateur GSI communiqué signé |
STS | Système OEM | utilisateurdebug | N | Oui | Nouveau dans Q |
STM | GSI | utilisateur | Oui | Oui | userdebug -> utilisateur GSI communiqué signé |
Aperçu
Ces fichiers image supplémentaires sont générés sous le dossier de construction ( ${ANDROID_PRODUCT_OUT}
) :
-
boot-debug.img
-
vendor_boot-debug.img
Lorsque boot-debug.img
est flashé sur la partition boot
du périphérique, la version userdebug du fichier de stratégie système et un fichier de propriétés supplémentaire, adb_debug.prop
, sont chargés. Cela permet à adb root
avec l'utilisateur de créer system.img
(soit GSI, soit OEM).
Pour l'image générique du noyau (GKI) utilisant des périphériques dotés d'une partition vendor_boot
, boot-debug.img
ne doit pas être flashé, car la partition boot
doit être flashée avec une image GKI certifiée. Au lieu de cela, vendor_boot-debug.img
doit être flashé sur la partition vendor_boot
afin de faciliter le débogage du disque virtuel.
Conditions préalables à l'utilisation d'un disque virtuel de débogage
Le disque virtuel de débogage est fourni par l’OEM exécutant les tests de conformité. Il ne doit pas être signé et il ne peut être utilisé que si l'appareil est déverrouillé.
Le disque virtuel de débogage ne sera pas généré ou utilisé pour mettre à niveau les appareils avec :
-
BOARD_BUILD_SYSTEM_ROOT_IMAGE
vrai -
skip_initramfs
dans la ligne de commande du noyau
Android 12 GSI
Aucune instruction supplémentaire n'est requise pour utiliser le disque virtuel de débogage avec Android 12 GSI.
À partir du 29/09/2021, les disques virtuels de débogage ne nécessitent plus de mise à jour avec l'outil repack_bootimg
. La version Android 12 GSI après SGR1.210929.001 (7777720)
intègre le fichier userdebug_plat_sepolicy.cil
à jour dans son system.img
et ignore userdebug_plat_sepolicy.cil
du disque virtuel de débogage. Voir les CL pour plus de détails.
Android 11 GSI
Lorsque boot-debug.img
ou vendor_boot-debug.img
est utilisé, la politique du système est chargée à partir du fichier userdebug_plat_sepolicy.cil
dans le disque virtuel de débogage de boot-debug.img
ou vendor_boot-debug.img
. Afin de démarrer les images GSI, veuillez toujours incorporer les modifications de politique de sécurité à jour de la branche android11-gsi
pour reconstruire votre boot-debug.img
ou vendor_boot-debug.img
.
Alternativement, l'outil repack_bootimg
peut être utilisé pour reconstruire un boot-debug.img
ou vendor_boot-debug.img
avec une politique GSI mise à jour.
Reconditionner un disque virtuel de débogage
Au lieu d'incorporer des modifications de stratégie de sécurité pour reconstruire boot-debug.img
, les partenaires peuvent utiliser repack_bootimg
pour mettre à jour le fichier de stratégie de sécurité GSI dans boot-debug.img
(ou vendor_boot-debug.img
si l'appareil utilise GKI).
Les étapes sont les suivantes:
Téléchargez
otatools.zip
depuis https://ci.android.com . Nous vous recommandons de télécharger à partir des artefacts de buildaosp_arm64-userdebug
suraosp-main
.Configurez l'environnement d'exécution pour
repack_bootimg
:unzip otatools.zip -d otatools
export PATH="${PWD}/otatools/bin:${PATH}"
repack_bootimg --help
Téléchargez le
userdebug_plat_sepolicy.cil
ouboot-with-debug-ramdisk-${KERNEL_VERSION}.img
à partir de la version GSI que vous utilisez. Par exemple, si vous utilisez un GSI arm64 deRJR1.211020.001 (7840830)
, téléchargez-le depuis https://ci.android.com/builds/submit/ 7840830 /aosp_arm64-user/latest .Mettez à jour le périphérique
boot-debug.img
ouvendor_boot-debug.img
avecuserdebug_plat_sepolicy.cil
:repack_bootimg --local --dst_bootimg boot-debug.img \ --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \ --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
# If using GKI
repack_bootimg --local --dst_bootimg vendor_boot-debug.img \ --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \ --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
Avec
boot-with-debug-ramdisk-${KERNEL_VERSION}.img
:repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \ --dst_bootimg boot-debug.img \ --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \ --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
# If using GKI
repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \ --dst_bootimg vendor_boot-debug.img \ --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \ --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
Les arguments de
--ramdisk_add
peuvent être ajustés en fonction des configurations du périphérique. Voir la section suivante pour une explication détaillée.
Chemin de la politique de débogage utilisateur
Le repack_bootimg
ci-dessus copie le fichier userdebug_plat_sepolicy.cil
du disque virtuel de --src_bootimg
vers le disque virtuel de --dst_bootimg
. Cependant, le chemin dans un disque virtuel de débogage peut être différent selon les versions d'Android. Sous Android 10 et 11, le chemin est first_stage_ramdisk/userdebug_plat_sepolicy.cil
pour les appareils avec androidboot.force_normal_boot=1
dans la ligne de commande du noyau. Sinon, le chemin est userdebug_plat_sepolicy.cil
.
Exécutez la commande suivante pour vérifier s'il existe androidboot.force_normal_boot
dans la ligne de commande du noyau :
adb root
adb shell cat /proc/cmdline | grep force_normal_boot
À partir d'Android 12, le chemin dans un disque virtuel de débogage est toujours userdebug_plat_sepolicy.cil
, quelle que soit l'existence de androidboot.force_normal_boot=1
dans la ligne de commande du noyau. Le tableau suivant montre les chemins au sein d'un disque virtuel de débogage dans différentes versions d'Android.
Image de débogage | Android 10 | Android 11 | Android 12 |
---|---|---|---|
Démarrage GKI avec-debug-ramdisk-${KERNEL_VERSION}.img | N / A | first_stage_ramdisk/userdebug_plat_sepolicy.cil | userdebug_plat_sepolicy.cil |
boot-debug.img spécifique au périphérique | Dépend de force_normal_boot | Dépend de force_normal_boot | userdebug_plat_sepolicy.cil |
Vendor_boot-debug.img spécifique à l'appareil | N / A | Dépend de force_normal_boot | userdebug_plat_sepolicy.cil |
Vous pouvez spécifier --ramdisk_add
pour copier des fichiers depuis et vers différents chemins avec une liste de paires src_path:dst_path
. Par exemple, la commande suivante copie le fichier first_stage_ramdisk/userdebug_plat_sepolicy.cil
d'un boot-with-debug-ramdisk-5.4.img
Android 11 vers first_stage_ramdisk/userdebug_plat_sepolicy.cil
dans un Android 11 vendor_boot-debug.img
.
repack_bootimg \
--src_bootimg boot-with-debug-ramdisk-5.4.img \
--dst_bootimg vendor_boot-debug.img \
--ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
S'il n'y a pas de androidboot.force_normal_boot=1
dans la ligne de commande du noyau, alors la commande doit être ajustée comme ci-dessous pour changer le chemin de destination en userdebug_plat_sepolicy.cil
.
repack_bootimg \
--src_bootimg boot-with-debug-ramdisk-5.4.img \
--dst_bootimg vendor_boot-debug.img \
--ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil
Ajouter un pied de page AVB
Si l'image transmise à --dst_bootimg
est configurée en tant que partition chaînée AVB , un pied de page AVB doit être ajouté après l'exécution de la commande repack_bootimg
.
Par exemple, avant d'exécuter repack_bootimg
, exécutez la commande suivante pour vérifier si un vendor_boot-debug.img
a un pied de page AVB chaîné.
avbtool info_image --image vendor_boot-debug.img
S'il comporte à l'origine un pied de page AVB chaîné, un pied de page AVB doit être ajouté après avoir exécuté la commande repack_bootimg
. L'utilisation de n'importe quelle clé de test pour signer le vendor_boot-debug.img
fonctionne car le disque virtuel de débogage ne peut être utilisé que lorsqu'un périphérique est déverrouillé, ce qui autorise des images signées par clé non libérée sur la partition boot
ou vendor_boot
.
avbtool add_hash_footer --partition_name vendor_boot \
--partition_size 100663296 \
--algorithm SHA256_RSA4096 \
--key otatools/external/avb/test/data/testkey_rsa4096.pem \
--image vendor_boot-debug.img