Test VTS con ramdisk di debug

A partire da Android 10, l' immagine di sistema generica (GSI) utilizzata per eseguire i test di conformità CTS-on-GSI/VTS è cambiata da userdebug a tipo di build utente per poter essere firmata. Questo è un problema per i test VTS perché VTS richiede l'esecuzione adb root , ma adb root non è disponibile su un dispositivo di build dell'utente.

Il ramdisk di debug (o immagine di avvio di debug) viene introdotto per abilitare adb root su un dispositivo creato dall'utente il cui bootloader è sbloccato . Ciò semplifica il flusso di test utilizzando lo stesso sistema GSI system.img creato dall'utente per CTS-on-GSI e VTS-on-GSI. Per la configurazione del servizio token di sicurezza, è ancora necessario utilizzare un altro userdebug OEM system.img .

La tabella seguente mostra le modifiche all'immagine e al tipo di build per i test di conformità in Android 10.

Suite di prova Prova con Costruire Eseguire il debug del ramdisk radice adb? Modifica della variante di build Android 9 -> 10
CTS Il sistema dell'OEM utente N N Nessun cambiamento
CTS su GSI GSI utente N N

userdebug -> utente GSI

liberatoria firmata

STS Il sistema dell'OEM userdebug N Y Novità in Q
VTS GSI utente Y Y

userdebug -> utente GSI

liberatoria firmata

Panoramica

Questi file di immagine aggiuntivi vengono generati nella cartella di build ( ${ANDROID_PRODUCT_OUT} ):

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

Quando boot-debug.img viene flashato sulla partizione boot del dispositivo, vengono caricati la versione userdebug del file sepolicy di sistema e un file di proprietà aggiuntivo, adb_debug.prop . Ciò consente adb root con la build dell'utente system.img (GSI o OEM).

Per Generic Kernel Image (GKI) che utilizzano dispositivi dotati di una partizione vendor_boot , boot-debug.img non deve essere flashato, poiché la partizione boot deve essere flashata con un'immagine GKI certificata. Invece vendor_boot-debug.img dovrebbe essere flashato sulla partizione vendor_boot per facilitare il debug del ramdisk.

Prerequisiti per l'utilizzo di un ramdisk di debug

Il ramdisk di debug viene fornito dall'OEM che esegue i test di conformità. Non deve essere firmata la release e può essere utilizzata solo se il dispositivo è sbloccato.

Il ramdisk di debug non verrà generato o utilizzato per aggiornare i dispositivi con:

  • BOARD_BUILD_SYSTEM_ROOT_IMAGE vero
  • skip_initramfs nella riga di comando del kernel

Android 12 GSI

Non sono necessarie istruzioni aggiuntive per utilizzare il ramdisk di debug con Android 12 GSI.

A partire dal 29/09/2021, i ramdisk di debug non richiedono più l'aggiornamento con lo strumento repack_bootimg . La build GSI di Android 12 successiva a SGR1.210929.001 (7777720) incorpora il file userdebug_plat_sepolicy.cil aggiornato nel suo system.img e ignora userdebug_plat_sepolicy.cil dal ramdisk di debug. Vedi i CL per i dettagli.

Android 11 GSI

Quando viene utilizzato boot-debug.img o vendor_boot-debug.img , la sepolicy del sistema viene caricata dal file userdebug_plat_sepolicy.cil nel ramdisk di debug di boot-debug.img o vendor_boot-debug.img . Per avviare le immagini GSI, incorpora sempre le modifiche sepolicy aggiornate dal ramo android11-gsi per ricostruire boot-debug.img o vendor_boot-debug.img .

In alternativa, è possibile utilizzare lo strumento repack_bootimg per ricostruire un boot-debug.img o vendor_boot-debug.img con la sepolicy GSI aggiornata.

Reimballare un ramdisk di debug

Invece di incorporare le modifiche alla sepolicy per ricostruire boot-debug.img , i partner possono utilizzare repack_bootimg per aggiornare il file sepolicy GSI in boot-debug.img (o vendor_boot-debug.img se il dispositivo utilizza GKI).

I passi sono come segue:

  1. Scarica otatools.zip da https://ci.android.com . Ti consigliamo di eseguire il download dagli artefatti di build di aosp_arm64-userdebug su aosp-main .

  2. Imposta l'ambiente di esecuzione per repack_bootimg :

    unzip otatools.zip -d otatools
    export PATH="${PWD}/otatools/bin:${PATH}"
    repack_bootimg --help
    
  3. Scarica userdebug_plat_sepolicy.cil o boot-with-debug-ramdisk-${KERNEL_VERSION}.img dalla build GSI che stai utilizzando. Ad esempio, se utilizzi un arm64 GSI da RJR1.211020.001 (7840830) , scaricalo da https://ci.android.com/builds/submission/ 7840830 /aosp_arm64-user/latest .

  4. Aggiorna il dispositivo boot-debug.img o vendor_boot-debug.img con 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
    

    Con 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
    

    Gli argomenti di --ramdisk_add possono essere modificati in base alle configurazioni del dispositivo. Vedere la sezione successiva per una spiegazione dettagliata.

Percorso della sepolicy userdebug

Il precedente repack_bootimg copia il file userdebug_plat_sepolicy.cil dal ramdisk di --src_bootimg al ramdisk di --dst_bootimg . Tuttavia, il percorso all'interno di un ramdisk di debug potrebbe essere diverso nelle diverse versioni di Android. In Android 10 e 11, il percorso è first_stage_ramdisk/userdebug_plat_sepolicy.cil per i dispositivi con androidboot.force_normal_boot=1 nella riga di comando del kernel. Altrimenti, il percorso è userdebug_plat_sepolicy.cil .

Esegui il comando seguente per verificare se è presente androidboot.force_normal_boot nella riga di comando del kernel:

adb root
adb shell cat /proc/cmdline | grep force_normal_boot

A partire da Android 12, il percorso all'interno di un ramdisk di debug è sempre userdebug_plat_sepolicy.cil , indipendentemente dall'esistenza di androidboot.force_normal_boot=1 nella riga di comando del kernel. La tabella seguente mostra i percorsi all'interno di un ramdisk di debug in diverse versioni di Android.

Immagine di debug Androide 10 Androide 11 Androide 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 specifico del dispositivo Dipende da force_normal_boot Dipende da force_normal_boot userdebug_plat_sepolicy.cil
Vendor_boot-debug.img specifico del dispositivo N / A Dipende da force_normal_boot userdebug_plat_sepolicy.cil

È possibile specificare --ramdisk_add per copiare file da e in percorsi diversi con un elenco di coppie src_path:dst_path . Ad esempio, il comando seguente copia il file first_stage_ramdisk/userdebug_plat_sepolicy.cil da un Android 11 boot-with-debug-ramdisk-5.4.img a first_stage_ramdisk/userdebug_plat_sepolicy.cil all'interno di 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

Se non è presente androidboot.force_normal_boot=1 nella riga di comando del kernel, il comando deve essere modificato come di seguito per modificare il percorso di destinazione in 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

Se l'immagine passata a --dst_bootimg è configurata come partizione concatenata AVB , è necessario aggiungere un piè di pagina AVB dopo aver eseguito il comando repack_bootimg .

Ad esempio, prima di eseguire repack_bootimg , esegui il comando seguente per verificare se un vendor_boot-debug.img ha un piè di pagina AVB concatenato.

avbtool info_image --image vendor_boot-debug.img

Se originariamente ha un piè di pagina AVB concatenato, è necessario aggiungere un piè di pagina AVB dopo aver eseguito il comando repack_bootimg . L'utilizzo di qualsiasi chiave di test per firmare il vendor_boot-debug.img funziona perché il ramdisk di debug può essere utilizzato solo quando un dispositivo è sbloccato, il che consente immagini firmate con chiave non di rilascio sulla partizione boot o 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