Test VTS con ramdisk di debug

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

Il ramdisk di debug (o l'immagine di avvio di debug) viene introdotto per attivare adb root su un dispositivo di compilazione dell'utente il cui bootloader è sbloccato. In questo modo, il flusso di test viene semplificato utilizzando la stessa build utente GSI system.img per CTS su GSI e VTS su GSI. Per la configurazione di STS, è ancora necessario utilizzare un altro OEM userdebug system.img.

La tabella seguente mostra le modifiche ai tipi di immagine e build per i test di conformità in Android 10.

Panoramica

Questi file di immagini aggiuntivi vengono generati nella cartella di compilazione (${ANDROID_PRODUCT_OUT}):

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

Quando boot-debug.img viene eseguito il flashing nella partizione boot del dispositivo, viene caricata la versione userdebug del file sepolicy di sistema e un file di proprietà aggiuntivo, adb_debug.prop. In questo modo, adb root può eseguire la compilazione dell'utentesystem.img (del GSI o dell'OEM).

Per Generic Kernel Image (GKI) che utilizzano dispositivi con una partizione vendor_boot, boot-debug.img non deve essere flashato, in quanto la partizione boot deve essere flashata con un'immagine GKI certificata. Invece, vendor_boot-debug.img deve essere eseguito il flashing 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 firmato e può essere utilizzato solo se il dispositivo è sbloccato.

Il ramdisk di debug non verrà generato o utilizzato per l'upgrade dei dispositivi con:

• BOARD_BUILD_SYSTEM_ROOT_IMAGE true
• skip_initramfs nella riga di comando del kernel

Android 12 GSI

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

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

GSI Android 11

Quando viene utilizzato boot-debug.img o vendor_boot-debug.img, il sistema sepolicy viene caricato dal file userdebug_plat_sepolicy.cil nella diga di ram di debug del boot-debug.img o del vendor_boot-debug.img. Per avviare le immagini GSI, incorpora sempre le modifiche aggiornate del criterio sepolicy dal ramo android11-gsi per ricostruire boot-debug.img o vendor_boot-debug.img.

In alternativa, lo strumento repack_bootimg potrebbe essere utilizzato per ricostruire un boot-debug.img o vendor_boot-debug.img con il file sepolicy di GSI aggiornato.

Riaccoppiare un ramdisk di debug

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

I passaggi sono i seguenti:

1. Scarica otatools.zip da https://ci.android.com. Consigliamo di scaricare gli elementi di compilazione di aosp_arm64-userdebug su aosp-main.

2. Configura 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 GSI arm64 daRJR1.211020.001 (7840830), scaricalo da https://ci.android.com/builds/submitted/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. Per una spiegazione dettagliata, consulta la sezione successiva.

Percorso del file sepolicy di userdebug

Il comando repack_bootimg riportato sopra copia il file userdebug_plat_sepolicy.cil dalla ramdisk di --src_bootimg alla ramdisk di --dst_bootimg. Tuttavia, il percorso all'interno di un ramdisk di debug potrebbe essere diverso nelle varie 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. In caso contrario, il percorso è userdebug_plat_sepolicy.cil.

Esegui il seguente comando 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.

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

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

Aggiungere un piè di pagina AVB

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

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

avbtool info_image --image vendor_boot-debug.img

Se inizialmente è presente un piè di pagina AVB a catena, è necessario aggiungerne uno dopo l'esecuzione del 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 chiavi non di release 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