Pruebas VTS con Debug Ramdisk

Desde Android 10, la imagen genérica del sistema (GSI) utilizada para ejecutar las pruebas de cumplimiento de CTS-on-GSI/VTS cambió de depuración de usuario a tipo de compilación de usuario para que se firmara la versión. Este es un problema para las pruebas de VTS porque VTS requiere adb root para ejecutarse, pero adb root no está disponible en un dispositivo de compilación de usuario.

El ramdisk de depuración (o imagen de arranque de depuración) se introduce para habilitar adb root en un dispositivo de compilación de usuario cuyo cargador de arranque está desbloqueado . Esto simplifica el flujo de prueba mediante el uso del mismo sistema GSI de compilación de system.img para CTS-on-GSI y VTS-on-GSI. Para la configuración de STS, aún se requiere el uso de otro system.img OEM de depuración de usuario.

En la siguiente tabla, se muestran los cambios de imagen y tipo de compilación para las pruebas de cumplimiento en Android 10.

Banco de pruebas	prueba con	Construir	Depurar ramdisk	raíz adb?	Cambio de variante de compilación de Android 9 -> 10
CTS	sistema de OEM	usuario	norte	norte	Ningún cambio
CTS en GSI	GSI	usuario	norte	norte	depuración de usuario -> usuario GSI liberación firmada
STS	sistema de OEM	depuración de usuario	norte	Y	Nuevo en Q
VTS	GSI	usuario	Y	Y	depuración de usuario -> usuario GSI liberación firmada

Nota: Los cambios de debug ramdisk en AOSP se identifican con el hashtag debug_ramdisk .

Visión de conjunto

Estos archivos de imagen adicionales se generan en la carpeta de compilación ( ${ANDROID_PRODUCT_OUT} ):

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

Cuando boot-debug.img se muestra en la partición de boot del dispositivo, se cargan la versión de depuración del usuario del archivo sepolicy del sistema y un archivo de propiedades adicional, adb_debug.prop . Esto permite que adb root rootee con el usuario build system.img (ya sea de GSI o de OEM).

Para la imagen de kernel genérica (GKI) que utiliza dispositivos que tienen una partición de arranque_proveedor, boot-debug.img vendor_boot debe actualizarse, ya que la partición de boot debe actualizarse con una imagen GKI certificada. En su lugar vendor_boot-debug.img debe actualizarse en la partición de vendor_boot para facilitar la depuración de ramdisk.

Requisitos previos para usar un ramdisk de depuración

El disco RAM de depuración lo proporciona el OEM que ejecuta las pruebas de cumplimiento. No debe estar firmado y solo se puede usar si el dispositivo está desbloqueado.

El ramdisk de depuración no se generará ni se utilizará para actualizar dispositivos con:

• BOARD_BUILD_SYSTEM_ROOT_IMAGE verdadero
• skip_initramfs en la línea de comando del kernel

Nota: Todos los dispositivos nuevos lanzados con Android 10 y superior deben usar initramfs para admitir particiones dinámicas .

Android 12 GSI

No se requieren instrucciones adicionales para usar ramdisk de depuración con Android 12 GSI.

A partir del 29/09/2021, los ramdisks de depuración ya no requieren actualización con la herramienta repack_bootimg . La compilación GSI de Android 12 posterior SGR1.210929.001 (7777720) incorpora el archivo userdebug_plat_sepolicy.cil actualizado en su system.img e ignora userdebug_plat_sepolicy.cil del ramdisk de depuración. Consulte las CL para obtener más información.

Android 11 GSI

Cuando se usa boot-debug.img o vendor_boot-debug.img , la política de seguridad del sistema se carga desde el archivo userdebug_plat_sepolicy.cil en el ramdisk de depuración de boot-debug.img o vendor_boot-debug.img . Para iniciar imágenes GSI, incorpore siempre los cambios actualizados en la política de seguridad de la rama android11-gsi para reconstruir su boot-debug.img o vendor_boot-debug.img .

Como alternativa, la herramienta repack_bootimg podría usarse para reconstruir boot-debug.img o vendor_boot-debug.img con la política de seguridad de GSI actualizada.

Reempaquetar un ramdisk de depuración

Nota: Puede dejar de leer ahora si se usa un Android 12 GSI con versión >= SGR1.210929.001 . Las siguientes secciones contienen los pasos de repack_bootimg , que solo se requieren cuando se usa un GSI de Android 11.

En lugar de incorporar cambios en la política de seguridad para reconstruir boot-debug.img , los socios pueden usar repack_bootimg para actualizar el archivo de política de seguridad de GSI en boot-debug.img (o vendor_boot-debug.img si el dispositivo usa GKI).

Los pasos son los siguientes:

1. Descargue otatools.zip desde https://ci.android.com . Recomendamos descargar desde los artefactos de compilación de aosp_arm64-userdebug en aosp-master .

2. Configure el entorno de ejecución para repack_bootimg :

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

3. Descargue userdebug_plat_sepolicy.cil o boot-with-debug-ramdisk-${KERNEL_VERSION}.img de la compilación de GSI que está utilizando. Por ejemplo, si usa un GSI arm64 de RJR1.211020.001 (7840830) , descárguelo desde https://ci.android.com/builds/submitted/ 7840830 /aosp_arm64-user/latest .

   Importante: El ${KERNEL_VERSION} es irrelevante aquí. Puede usar cualquiera de los boot-with-debug-ramdisk-${KERNEL_VERSION}.img .
   Nota: Desde el 27/09/2021, boot-debug-${KERNEL_VERSION}.img en una compilación de GSI cambia de nombre a boot-with-debug-ramdisk-${KERNEL_VERSION}.img .

4. Actualice el 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
   

   Los argumentos de --ramdisk_add se pueden ajustar según las configuraciones del dispositivo. Consulte la siguiente sección para obtener una explicación detallada.

   Nota: Consulte repack_bootimg --help para ver ejemplos y usos detallados.

Ruta de la política de depuración del usuario

El repack_bootimg anterior copia el archivo userdebug_plat_sepolicy.cil del ramdisk de --src_bootimg al ramdisk de --dst_bootimg . Sin embargo, la ruta dentro de un ramdisk de depuración puede ser diferente en diferentes versiones de Android. En Android 10 y 11, la ruta es first_stage_ramdisk/userdebug_plat_sepolicy.cil para dispositivos con androidboot.force_normal_boot=1 en la línea de comandos del kernel. De lo contrario, la ruta es userdebug_plat_sepolicy.cil .

Ejecute el siguiente comando para comprobar si hay androidboot.force_normal_boot en la línea de comandos del kernel:

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

A partir de Android 12, la ruta dentro de un ramdisk de depuración siempre es userdebug_plat_sepolicy.cil , independientemente de la existencia de androidboot.force_normal_boot=1 en la línea de comandos del kernel. La siguiente tabla muestra las rutas dentro de un ramdisk de depuración en diferentes versiones de Android.

Imagen de depuración	androide 10	androide 11	androide 12
Arranque GKI con depuración-ramdisk-${KERNEL_VERSION}.img	N / A	first_stage_ramdisk/userdebug_plat_sepolicy.cil	userdebug_plat_sepolicy.cil
boot-debug.img específico del dispositivo	Depende de force_normal_boot	Depende de force_normal_boot	userdebug_plat_sepolicy.cil
Vendor_boot-debug.img específico del dispositivo	N / A	Depende de force_normal_boot	userdebug_plat_sepolicy.cil

Puede especificar --ramdisk_add para copiar archivos desde y hacia diferentes rutas con una lista de pares src_path:dst_path . Por ejemplo, el siguiente comando copia el archivo first_stage_ramdisk/userdebug_plat_sepolicy.cil de un boot-with-debug-ramdisk-5.4.img de Android 11 a first_stage_ramdisk/userdebug_plat_sepolicy.cil dentro de un vendor_boot-debug.img de 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 no hay androidboot.force_normal_boot=1 en la línea de comando del kernel, entonces el comando debe ajustarse como se muestra a continuación para cambiar la ruta de destino a 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

Agregar un pie de página AVB

Si la imagen pasada a --dst_bootimg está configurada como una partición en cadena AVB, se debe agregar un pie de página AVB después de ejecutar el comando repack_bootimg .

Por ejemplo, antes de ejecutar repack_bootimg , ejecute el siguiente comando para verificar si un vendor_boot-debug.img tiene un pie de página AVB encadenado.

avbtool info_image --image vendor_boot-debug.img

Si originalmente tiene un pie de página AVB encadenado, se debe agregar un pie de página AVB después de ejecutar el comando repack_bootimg . El uso de cualquier clave de prueba para firmar el vendor_boot-debug.img funciona porque el ramdisk de depuración solo se puede usar cuando un dispositivo está desbloqueado, lo que permite imágenes firmadas con clave sin liberación en la partición de 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

Importante: el número pasado a --partition_size debe ajustarse en función del tamaño de partición específico del dispositivo, por ejemplo, el tamaño de la partición de vendor_boot del dispositivo.