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 à user build type afin d'être signée. Cela pose problème pour les tests VTS, car VTS nécessite l'exécution de adb root
, mais adb root
n'est pas disponible sur un appareil de compilation utilisateur.
Le ramdisk de débogage (ou image de démarrage de débogage) est introduit pour activer adb root
sur un appareil de compilation utilisateur dont le bootloader est déverrouillé. Cela simplifie le flux de test en utilisant le même system.img
GSI de compilation utilisateur pour CTS-on-GSI et VTS-on-GSI. Pour la configuration du STS, l'utilisation d'un autre system.img
OEM userdebug est toujours requise.
Le tableau suivant présente 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 le ramdisk | adb root ? | Modification de la variante de compilation Android 9 -> 10 |
---|---|---|---|---|---|
CTS | Système OEM | utilisateur | N | N | Aucun changement |
CTS-on-GSI | GSI | utilisateur | N | N | userdebug -> GSI utilisateur version signée |
STS | Système de l'OEM | userdebug | N | O | Nouveautés de Q |
VTS | GSI | utilisateur | O | O | userdebug -> GSI utilisateur version signée |
Présentation
Ces fichiers image supplémentaires sont générés dans 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, la version userdebug du fichier sepolicy du système et un fichier de propriétés supplémentaire, adb_debug.prop
, sont chargés. Cela permet d'autoriser adb root
avec le build system.img
de l'utilisateur (GSI ou OEM).
Pour les images de kernel génériques (GKI, Generic Kernel Image) utilisant des appareils 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.
À la place, vendor_boot-debug.img
doit être flashé sur la partition vendor_boot
afin de faciliter le débogage du ramdisk.
Conditions préalables à l'utilisation d'un disque RAM de débogage
Le ramdisk de débogage est fourni par l'OEM qui exécute les tests de conformité. Il ne doit pas être signé pour la publication et ne peut être utilisé 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
Image système générique Android 12
Aucune instruction supplémentaire n'est requise pour utiliser le ramdisk de débogage avec le GSI Android 12.
À partir du 29/09/2021, les ramdisks de débogage ne nécessitent plus de mise à jour avec l'outil repack_bootimg
. La version GSI d'Android 12 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
à partir du ramdisk de débogage. Pour en savoir plus, consultez les CL.
Image système générique Android 11
Lorsque boot-debug.img
ou vendor_boot-debug.img
est utilisé, la définition système est chargée à partir du fichier userdebug_plat_sepolicy.cil
du disque RAM de débogage de boot-debug.img
ou de vendor_boot-debug.img
. Pour démarrer des images GSI, veuillez toujours intégrer les dernières modifications de la stratégie de sécurité de la branche android11-gsi
afin de recompiler votre boot-debug.img
ou votre vendor_boot-debug.img
.
Vous pouvez également utiliser l'outil repack_bootimg
pour reconstruire un boot-debug.img
ou un vendor_boot-debug.img
avec une mise à jour de la stratégie de sécurité GSI.
Réempaqueter un disque RAM de débogage
Au lieu d'intégrer des modifications de sepolicy pour reconstruire boot-debug.img
, les partenaires peuvent utiliser repack_bootimg
pour mettre à jour le fichier de règles de sécurité GSI dans boot-debug.img
(ou vendor_boot-debug.img
si l'appareil utilise GKI).
La procédure est la suivante:
Téléchargez
otatools.zip
sur https://ci.android.com. Nous vous recommandons de le télécharger à partir des artefacts de compilation deaosp_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
userdebug_plat_sepolicy.cil
ouboot-with-debug-ramdisk-${KERNEL_VERSION}.img
à partir du build GSI que vous utilisez. Par exemple, si vous utilisez un GSI arm64 à partir deRJR1.211020.001 (7840830)
, téléchargez-le sur https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest.Mettez à 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 des configurations de l'appareil. Pour en savoir plus, consultez la section suivante.
Chemin d'accès de la règle de débogage userdebug
repack_bootimg
ci-dessus copie le fichier userdebug_plat_sepolicy.cil
du 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. Sous Android 10 et 11, le chemin d'accès est first_stage_ramdisk/userdebug_plat_sepolicy.cil
pour les appareils dont l'élément androidboot.force_normal_boot=1
est présent dans la ligne de commande du noyau. Sinon, le chemin d'accès est userdebug_plat_sepolicy.cil
.
Exécutez la commande suivante pour vérifier si androidboot.force_normal_boot
figure 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 ramdisk 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 kernel. Le tableau suivant présente les chemins d'accès dans un ramdisk 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 |
Fichier boot-debug.img spécifique à l'appareil | 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 à l'aide d'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 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 aucun androidboot.force_normal_boot=1
n'est défini dans la ligne de commande du kernel, la commande doit être ajustée comme indiqué 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 partition AVB-chained, 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
possède un pied de page AVB en chaîne.
avbtool info_image --image vendor_boot-debug.img
S'il comporte à l'origine un pied de page AVB en chaîne, un pied de page AVB doit être ajouté après l'exécution de la commande repack_bootimg
. L'utilisation d'une clé de test pour signer vendor_boot-debug.img
fonctionne, car le ramdisk de débogage ne peut être utilisé que lorsqu'un appareil est déverrouillé, ce qui permet d'utiliser des images signées par une clé non publié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