Depuis Android 10,
Image système générique (GSI) utilisée pour s'exécuter
Tests de conformité CTS-on-GSI/VTS modifiés
du type de compilation "userdebug" au type de compilation "user" pour que la version soit signée. Il s'agit d'un
pour les tests VTS, car il nécessite
adb root
, mais
adb root
n'est pas disponible sur un appareil de build d'utilisateur.
Le disque RAM de débogage (ou image de démarrage de débogage) est introduit pour activer adb root
sur une
appareil de build de l'utilisateur dont le bootloader est
déverrouillée. Cela simplifie les tests
en utilisant le même build d'utilisateur GSI system.img
pour CTS-on-GSI et
VTS sur GSI. Pour la configuration STS, l'utilisation d'un autre system.img
OEM pour le débogage utilisateur reste
obligatoire.
Le tableau suivant montre les modifications apportées aux images et aux types de compilation pour les tests de conformité dans Android 10.
Suite de tests | Tester avec | Créer | Déboguer ramdisk | Racine adb ? | Android 9 -> 10 modifications de variante de compilation |
---|---|---|---|---|---|
CTS | Système OEM | utilisateur | N | N | Aucun changement |
CTS sur GSI | GSI | utilisateur | N | N | débogage utilisateur -> GSI utilisateur version signée |
STS | Système OEM | débogage utilisateur | N | O | Nouveautés du trimestre |
VTS | GSI | utilisateur | O | O | débogage utilisateur -> GSI utilisateur version signée |
Présentation
Ces fichiers image supplémentaires sont générés sous le dossier de compilation
(${ANDROID_PRODUCT_OUT}
):
boot-debug.img
vendor_boot-debug.img
Lorsque boot-debug.img
est flashé sur la partition boot
de l'appareil, le
userdebug du fichier système sepolicy et un fichier de propriétés supplémentaire,
adb_debug.prop
sont chargés. Cela permet à adb root
avec le build de l'utilisateur
system.img
(GSI ou OEM).
Pour
Image du noyau générique (GKI)
utilisant des périphériques ayant 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.
À la place, vendor_boot-debug.img
doit être flashé sur vendor_boot
.
partition afin de faciliter
le débogage de ramdisk.
Conditions préalables à l'utilisation d'un disque RAM de débogage
Le disque RAM de débogage est fourni par l'OEM qui exécute les tests de conformité. Il ne doivent pas être signées et ne peuvent être utilisées que si l'appareil est déverrouillé.
Le disque RAM de débogage ne sera pas généré ni utilisé pour mettre à niveau les appareils avec:
BOARD_BUILD_SYSTEM_ROOT_IMAGE
vraiskip_initramfs
dans la ligne de commande du noyau
Images système génériques Android 12
Aucune instruction supplémentaire n'est requise pour utiliser le ramdisk de débogage avec les GSI Android 12.
Depuis le 29/09/2021, il n'est plus nécessaire de mettre à jour les ramdisks de débogage avec
repack_bootimg
. Images système génériques Android 12
une fois que SGR1.210929.001 (7777720)
aura intégré les mises à jour
userdebug_plat_sepolicy.cil
dans son system.img
et ignore
userdebug_plat_sepolicy.cil
à partir du disque RAM de débogage. Consultez le
CL pour
plus de détails.
Images système génériques Android 11
Lorsque boot-debug.img
ou vendor_boot-debug.img
est utilisé, le système
sepolicy est chargé à partir du fichier userdebug_plat_sepolicy.cil
dans l'outil de débogage
ramdisk de boot-debug.img
ou vendor_boot-debug.img
. Pour démarrer GSI
images, veuillez toujours intégrer les dernières modifications apportées aux règles
android11-gsi
pour recréer votre boot-debug.img
ou vendor_boot-debug.img
.
Vous pouvez également utiliser l'outil repack_bootimg
pour recréer un
boot-debug.img
ou vendor_boot-debug.img
avec la stratégie de sécurité GSI mise à jour.
Réempaqueter un disque RAM de débogage
Au lieu d'intégrer les changements de règles pour recréer boot-debug.img
, les partenaires
Vous pouvez utiliser repack_bootimg
pour mettre à jour le fichier de règles GSI dans boot-debug.img
.
(ou vendor_boot-debug.img
si l'appareil utilise GKI).
Les étapes sont les suivantes:
Télécharger
otatools.zip
depuis https://ci.android.com Nous vous recommandons de télécharger l'application à partir des artefacts de compilation deaosp_arm64-userdebug
leaosp-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
du build GSI que vous utilisez utilisent. Par exemple, si vous utilisez une GSI arm64 à partir deRJR1.211020.001 (7840830)
, puis téléchargez depuis https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latestMettez à jour l'appareil
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 de l'appareil de configuration. Consultez la section suivante pour en savoir plus explicative.
Chemin d'accès à la règle de débogage userdebug
Le repack_bootimg
ci-dessus copie le fichier userdebug_plat_sepolicy.cil
à partir de
ramdisk de --src_bootimg
vers le ramdisk de --dst_bootimg
. Toutefois, le chemin d'accès
dans un ramdisk de débogage peut
être différent selon les versions d'Android. Dans
Android 10 et 11, le chemin d'accès est
first_stage_ramdisk/userdebug_plat_sepolicy.cil
pour les appareils avec
androidboot.force_normal_boot=1
dans la ligne de commande du noyau. Dans le cas contraire,
chemin d'accès est userdebug_plat_sepolicy.cil
.
Exécutez la commande suivante pour vérifier la présence de 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 d'accès dans un fichier de débogage
ramdisk est toujours userdebug_plat_sepolicy.cil
, quelle que soit l'existence de
androidboot.force_normal_boot=1
dans la ligne de commande du noyau. Les éléments suivants :
affiche les chemins d'accès au sein d'un disque RAM de débogage dans différentes versions d'Android.
Image de débogage | Android 10 | Android 11 | Android 12 |
---|---|---|---|
GKI boot-with-debug-ramdisk-${KERNEL_VERSION}.img | N/A | first_stage_ramdisk/userdebug_plat_sepolicy.cil |
userdebug_plat_sepolicy.cil |
boot-debug.img spécifique à l'appareil | Dépend de force_normal_boot | Dépend de force_normal_boot | userdebug_plat_sepolicy.cil |
Provider_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 d'accès à l'aide d'un
liste de paires src_path:dst_path
. Par exemple, la commande suivante copie
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 vendor_boot-debug.img
Android 11.
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
Si androidboot.force_normal_boot=1
ne figure pas dans la ligne de commande du noyau,
la commande doit être ajustée comme
ci-dessous pour remplacer le chemin de destination par
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
Enchaînement AVB
un pied de page AVB doit être ajouté après l'exécution de 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 enchaîné.
avbtool info_image --image vendor_boot-debug.img
S'il comporte à l'origine un pied de page AVB enchaîné, un pied de page AVB doit être ajouté
après l'exécution de la commande repack_bootimg
. En utilisant n'importe quelle clé de test
vendor_boot-debug.img
fonctionne, car le disque RAM de débogage ne peut être utilisé que lorsqu'un
l'appareil est déverrouillé, ce qui permet d'obtenir des images signées sans la libération de la clé sur le 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