Test VTS avec Debug Ramdisk

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. C'est un 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 construction 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 construction utilisateur dont le chargeur de démarrage est déverrouillé . Cela simplifie le flux de test en utilisant le même fichier utilisateur GSI system.img pour CTS-on-GSI et VTS-on-GSI. Pour la configuration STS, l'utilisation d'un autre userdebug OEM system.img est toujours nécessaire.

Le tableau suivant montre les changements d'image et de type de build pour les tests de conformité dans Android 10.

Suite de tests Testez avec Construire Déboguer le disque virtuel racine adb? Android 9 -> 10 changement de variante de construction
CTS Le système OEM utilisateur N N Pas de changement
CTS sur GSI GSI utilisateur N N

userdebug -> utilisateur GSI

décharge signée

STS Le système OEM débogage utilisateur N Oui Nouveau dans Q
VTS GSI utilisateur Oui Oui

userdebug -> utilisateur GSI

décharge signée

Aperçu

Ces fichiers image supplémentaires sont générés dans le dossier build ( ${ANDROID_PRODUCT_OUT} ) :

  • boot-debug.img
  • vendor_boot-debug.img

Lorsque boot-debug.img est flashé sur la partition de boot du périphérique, la version userdebug du fichier sepolicy système et un fichier de propriétés supplémentaire, adb_debug.prop , sont chargés. Cela permet à adb root avec l'utilisateur build system.img (GSI ou 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 de 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 ramdisk.

Prérequis pour utiliser un ramdisk de débogage

Le disque RAM de débogage est fourni par l'OEM exécutant les tests de conformité. Il ne doit pas être signé 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 la mise à niveau des appareils avec :

  • BOARD_BUILD_SYSTEM_ROOT_IMAGE vrai
  • skip_initramfs dans la ligne de commande du noyau

Android 12GSI

Aucune instruction supplémentaire n'est requise pour utiliser le disque RAM de débogage avec Android 12 GSI.

À partir du 29/09/2021, les disques RAM de débogage ne nécessitent plus de mise à jour avec l'outil repack_bootimg . Android 12 GSI build 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. Voir les CL pour plus de détails.

Android 11GSI

Lorsque boot-debug.img ou vendor_boot-debug.img est utilisé, la sepolicy 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 . 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 stratégie GSI mise à jour.

Remballer un ramdisk de débogage

Au lieu d'incorporer des changements de politique pour reconstruire boot-debug.img , les partenaires peuvent utiliser repack_bootimg pour mettre à jour le fichier de politique GSI dans boot-debug.img (ou vendor_boot-debug.img si l'appareil utilise GKI).

Les étapes sont les suivantes:

  1. Téléchargez otatools.zip depuis https://ci.android.com . Nous vous recommandons de télécharger à partir des artefacts de construction de aosp_arm64-userdebug sur aosp-master .

  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 userdebug_plat_sepolicy.cil ou boot-with-debug-ramdisk-${KERNEL_VERSION}.img à partir de la version GSI que vous utilisez. Par exemple, si vous utilisez un GSI arm64 de RJR1.211020.001 (7840830) , téléchargez-le depuis https://ci.android.com/builds/submitted/ 7840830 /aosp_arm64-user/latest .

  4. Mettez à jour le périphérique boot-debug.img ou vendor_boot-debug.img 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 périphérique. Voir la section suivante pour une explication détaillée.

Chemin de la sepolicy userdebug

Le repack_bootimg ci-dessus copie le fichier userdebug_plat_sepolicy.cil du ramdisk de --src_bootimg vers le ramdisk de --dst_bootimg . Cependant, le chemin d'accès dans un disque RAM de débogage peut être différent dans différentes versions d'Android. Dans 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 y a 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 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 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
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 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 Android 11 boot-with-debug-ramdisk-5.4.img 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 androidboot.force_normal_boot=1 dans la ligne de commande du noyau, 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

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 a à 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 de n'importe quelle 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 périphérique est déverrouillé, ce qui autorise les images signées par clé non-release 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