Test VTS avec ramdisk de débogage

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 du type de build userdebug au type de build user afin d'être signée pour la publication. Cela pose problème pour les tests VTS, car ils nécessitent l'exécution de adb root, mais adb root n'est pas disponible sur un appareil avec une version 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 la même image système générique (GSI) system.img pour les tests CTS-on-GSI et VTS-on-GSI. Pour la configuration de STS, il est toujours nécessaire d'utiliser un autre system.img OEM userdebug.

Le tableau suivant présente les modifications apportées aux images et aux types de compilation pour les tests de conformité dans Android 10.

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 à adb root d'utiliser la version utilisateur system.img (GSI ou OEM).

Pour Generic Kernel Image (GKI), les appareils utilisant une partition vendor_boot ne doivent pas flasher boot-debug.img, 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 ramdisk de débogage.

Conditions préalables à l'utilisation d'un ramdisk 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 version et ne peut être utilisé que si l'appareil est déverrouillé.

Le ramdisk de débogage ne sera pas généré ni utilisé pour la mise à niveau des appareils avec :

• BOARD_BUILD_SYSTEM_ROOT_IMAGE true
• skip_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 l'image système générique Android 12.

Depuis le 29/09/2021, les ramdisks de débogage ne nécessitent plus de mise à jour avec l'outil repack_bootimg. La version GSI 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 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 stratégie sepolicy du système est chargée à partir du fichier userdebug_plat_sepolicy.cil dans le ramdisk de débogage de boot-debug.img ou vendor_boot-debug.img. Pour démarrer des images GSI, veuillez toujours intégrer les modifications sepolicy à jour de la branche android11-gsi pour reconstruire 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 un vendor_boot-debug.img avec la stratégie SELinux de l'image système générique mise à jour.

Reconditionner un ramdisk de débogage

Au lieu d'intégrer les modifications de sepolicy pour reconstruire boot-debug.img, les partenaires peuvent utiliser repack_bootimg pour mettre à jour le fichier sepolicy GSI dans boot-debug.img (ou vendor_boot-debug.img si l'appareil utilise GKI).

Voici la procédure à suivre :

1. Téléchargez otatools.zip depuis https://ci.android.com. Nous vous recommandons de télécharger les artefacts de compilation de aosp_cf_arm64_only_phone-userdebug sur la branche aosp-android-latest-release.

2. Configurez l'environnement d'exécution pour repack_bootimg :

   unzip otatools.zip -d otatools
   export PATH="${PWD}/otatools/bin:${PATH}"
   repack_bootimg --help

3. Téléchargez le fichier userdebug_plat_sepolicy.cil ou boot-with-debug-ramdisk-${KERNEL_VERSION}.img à partir de la compilation GSI que vous utilisez. Par exemple, si vous utilisez une GSI arm64 à partir de RJR1.211020.001 (7840830), téléchargez-la depuis https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest.

4. Mettez à jour boot-debug.img ou vendor_boot-debug.img de l'appareil avec userdebug_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 à la stratégie SELinux userdebug

La commande repack_bootimg ci-dessus copie le fichier userdebug_plat_sepolicy.cil du disque RAM de --src_bootimg vers le disque RAM de --dst_bootimg. Toutefois, le chemin d'accès dans un ramdisk de débogage peut varier 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. Sinon, le chemin d'accès est userdebug_plat_sepolicy.cil.

Exécutez la commande suivante pour vérifier si androidboot.force_normal_boot se trouve 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 noyau. Le tableau suivant indique les chemins d'accès dans un ramdisk de débogage pour différentes versions d'Android.

Vous pouvez spécifier --ramdisk_add pour copier des fichiers depuis et vers différents chemins d'accès 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 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 n'est pas présent dans la ligne de commande du noyau, la commande doit être ajustée comme ci-dessous pour modifier 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 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 comporte 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 l'exécution de la commande repack_bootimg. L'utilisation d'une clé de test pour signer le vendor_boot-debug.img fonctionne, car le disque RAM 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 publique 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