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

Desde Android 10, la imagen genérica del sistema (GSI) que se usa para ejecutar las pruebas de cumplimiento de CTS en GSI/VTS cambió de userdebug a tipo de compilación del usuario para poder firmarse para el lanzamiento. Esto es un problema para las pruebas de VTS, ya que VTS requiere que se ejecute adb root, pero adb root no está disponible en un dispositivo de compilación de usuario.

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

En la siguiente tabla, se muestran los cambios en los tipos de imágenes y compilaciones para las pruebas de cumplimiento en Android 10.

Paquete de pruebas Prueba con Compilación Ramdisk de depuración ¿adb root? Cambio de la 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 de usuario

Versión firmada
STS Sistema del OEM userdebug N S Novedades del trimestre
VTS GSI user S S

userdebug -> GSI de usuario

Versión firmada

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 cargan la versión userdebug del archivo sepolicy del sistema y un archivo de propiedades adicional, adb_debug.prop. Esto permite adb root con la compilación de usuario system.img (ya sea la GSI o la del OEM).

Para la imagen genérica del kernel (GKI), en los dispositivos que tienen una partición vendor_boot, no se debe escribir boot-debug.img en la memoria flash, ya que la partición boot se debe escribir en la memoria flash con una imagen de GKI certificada. En su lugar, se debe escribir vendor_boot-debug.img en la partición vendor_boot para facilitar el disco RAM de depuración.

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 estar firmado para el lanzamiento y solo se puede usar si el dispositivo está desbloqueado.

El ramdisk de depuración no se generará ni se usará para actualizar dispositivos con las siguientes características:

  • 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, los ramdisks de depuración ya no requieren actualización con la herramienta repack_bootimg. La compilación de la GSI de Android 12 posterior a SGR1.210929.001 (7777720) incorpora el archivo userdebug_plat_sepolicy.cil actualizado en su system.img y omite 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 disco RAM de depuración de boot-debug.img o vendor_boot-debug.img. Para iniciar imágenes de la GSI, siempre incorpora los cambios actualizados de sepolicy de la rama android11-gsi para volver a compilar tu boot-debug.img o vendor_boot-debug.img.

Como alternativa, se podría usar la herramienta repack_bootimg para volver a compilar un boot-debug.img o un vendor_boot-debug.img con la sepolicy de la GSI actualizada.

Cómo volver a empaquetar un ramdisk de depuración

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

Los pasos son los siguientes:

  1. Descarga otatools.zip desde https://ci.android.com. Te recomendamos que lo descargues desde los artefactos de compilación de aosp_cf_arm64_only_phone-userdebug en la rama aosp-android-latest-release.

  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 userdebug_plat_sepolicy.cil o boot-with-debug-ramdisk-${KERNEL_VERSION}.img desde la compilación de GSI que estás usando. Por ejemplo, si usas una GSI de arm64 de RJR1.211020.001 (7840830), descárgala desde 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 sepolicy de userdebug

El comando repack_bootimg anterior copia el archivo userdebug_plat_sepolicy.cil del disco RAM de --src_bootimg al disco RAM de --dst_bootimg. Sin embargo, la ruta de acceso dentro de un disco RAM de depuración puede ser diferente en distintas versiones de Android. En Android 10 y 11, la ruta de acceso es first_stage_ramdisk/userdebug_plat_sepolicy.cil para los 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 disco RAM 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 disco RAM 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 diferentes rutas de acceso y hacia ellas 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 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 pasó a --dst_bootimg está configurada como una partición encadenada por 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 de AVB encadenado.

avbtool info_image --image vendor_boot-debug.img

Si originalmente tiene un pie de página de AVB encadenado, se debe agregar un pie de página de 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 disco RAM de depuración solo se puede usar cuando un dispositivo está desbloqueado, 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