Cómo evaluar el VTS con ramdisk de depuración

A partir de Android 10, la imagen genérica del sistema (GSI) que se usaba para ejecutar pruebas de cumplimiento de CTS en GSI/VTS cambió de userdebug a tipo de compilación de usuario para que se firme su lanzamiento. Este es un problema para las pruebas de VTS porque requiere adb root para ejecutarse, pero adb root no está disponible en un dispositivo de compilación de usuarios.

Se introduce el ramdisk de depuración (o la imagen de arranque de depuración) para habilitar adb root en un dispositivo de compilación del usuario cuyo bootloader está desbloqueado. De esta manera, se simplifica el flujo de prueba mediante el uso de la misma GSI system.img de compilación del usuario para CTS en GSI y VTS en GSI. Para la configuración de STS, aún se requiere usar otro system.img de OEM de userdebug.

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

Paquete de pruebas Prueba con Compilación Ramdisk de depuración ¿adb root? Cambio de variante de compilación de Android 9 a 10
CTS Sistema del OEM user N N Sin cambios
CTS-on-GSI GSI user N N

userdebug -> GSI del usuario

versión firmada
STS Sistema del OEM userdebug N S Novedad en Q
VTS GSI user S S

userdebug -> GSI del usuario

firma del lanzamiento

Descripción general

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

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

Cuando se escribe boot-debug.img en la partición boot del dispositivo, se carga la versión de userdebug del archivo sepolicy del sistema y un archivo de propiedades adicional, adb_debug.prop. Esto permite que adb root tenga la compilación del usuario system.img (la GSI o la del OEM).

En el caso de la imagen genérica del kernel (GKI) que usa dispositivos con una partición vendor_boot, no se debe escribir en boot-debug.img, ya que la partición boot se debe escribir con una imagen GKI certificada. En su lugar, vendor_boot-debug.img se debe escribir en la partición vendor_boot para facilitar la depuración del ramdisk.

Requisitos previos para usar un ramdisk de depuración

El OEM que ejecuta las pruebas de cumplimiento proporciona el ramdisk de depuración. No debe tener una firma de lanzamiento y solo se puede usar si el dispositivo está desbloqueado.

No se generará ni se usará el ramdisk de depuración para actualizar dispositivos con lo siguiente:

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

GSI de Android 12

No se requiere ninguna instrucción adicional para usar el ramdisk de depuración con la GSI de Android 12.

A partir del 29/09/2021, ya no es necesario actualizar los ramdisks de depuración con la herramienta repack_bootimg. Compilación de GSI de Android 12 después de que SGR1.210929.001 (7777720) incorpore el archivo userdebug_plat_sepolicy.cil actualizado en su system.img y omita userdebug_plat_sepolicy.cil del ramdisk de depuración. Consulta las CL para obtener más detalles.

GSI de Android 11

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 de GSI, siempre incorpora los cambios de sepolicy actualizados de la rama android11-gsi para volver a compilar tu boot-debug.img o vendor_boot-debug.img.

Como alternativa, se puede usar la herramienta repack_bootimg para volver a compilar una boot-debug.img o una vendor_boot-debug.img con la política de GSI actualizada.

Vuelve a empaquetar un ramdisk de depuración

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

Los pasos son los siguientes:

  1. Descarga otatools.zip de https://ci.android.com. Te recomendamos que descargues desde los artefactos de compilación de aosp_arm64-userdebug en aosp-main.

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

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

  3. Descarga el userdebug_plat_sepolicy.cil o boot-with-debug-ramdisk-${KERNEL_VERSION}.img de la compilación de GSI que usas. Por ejemplo, si usas una GSI arm64 de RJR1.211020.001 (7840830), descárgala de https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest.

  4. Actualiza 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 la configuración del dispositivo. Consulta la siguiente sección para obtener una explicación detallada.

Ruta de acceso de la política de SE de userdebug

El comando repack_bootimg anterior copia el archivo userdebug_plat_sepolicy.cil del almacenamiento en búfer de --src_bootimg al almacenamiento en búfer 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 de acceso 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.

Ejecuta el siguiente comando para verificar 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 de acceso 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. En la siguiente tabla, se muestran las rutas de acceso dentro de un ramdisk de depuración en diferentes versiones de Android.

Imagen de depuración 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 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

Puedes especificar --ramdisk_add para copiar archivos desde y hacia diferentes rutas de acceso 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 una boot-with-debug-ramdisk-5.4.img de Android 11 a first_stage_ramdisk/userdebug_plat_sepolicy.cil dentro de una 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 comandos del kernel, el comando se debe ajustar como se indica 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

Si la imagen que se pasa a --dst_bootimg se configura como una partición encadenada de AVB, se debe agregar un pie de página de AVB después de ejecutar el comando repack_bootimg.

Por ejemplo, antes de ejecutar repack_bootimg, ejecuta 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 se desbloquea un dispositivo, lo que permite imágenes firmadas con claves que no son de lanzamiento en la partición 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