Esta página se ha traducido con Cloud Translation API.

Pruebas VTS con ramdisk de depuración

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 poder firmar la versión. Esto 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 disco ram 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 gestor de arranque está desbloqueado . Esto simplifica el flujo de pruebas al utilizar la misma compilación de usuario GSI system.img para CTS-on-GSI y VTS-on-GSI. Para la configuración de STS, todavía se requiere utilizar otro system.img OEM de depuración de usuario.img.

La siguiente tabla muestra los cambios de imagen y tipo de compilación para las pruebas de cumplimiento en Android 10.

Banco de pruebas	Prueba con	Construir	Depurar disco RAM	¿raíz adb?	Android 9 -> 10 cambio de variante de compilación
cts	sistema OEM	usuario	norte	norte	Ningún cambio
CTS en GSI	GSI	usuario	norte	norte	depuración de usuario -> usuario GSI comunicado firmado
SAS	sistema OEM	depuración de usuario	norte	Y	Nuevo en Q
VTS	GSI	usuario	Y	Y	depuración de usuario -> usuario GSI comunicado firmado

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 boot-debug.img se actualiza en la partición 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 adb root con el usuario build system.img (ya sea GSI o OEM).

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

Requisitos previos para utilizar un disco RAM de depuración

El disco ram de depuración lo proporciona el OEM que ejecuta las pruebas de cumplimiento. No debe tener firma de autorización y solo se puede utilizar si el dispositivo está desbloqueado.

El disco ram 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

Android 12 GSI

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

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

Android 11 GSI

Cuando se utiliza boot-debug.img o vendor_boot-debug.img , la política 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 GSI, incorpore siempre cambios de política actualizados de la rama android11-gsi para reconstruir su boot-debug.img o vendor_boot-debug.img .

Alternativamente, la herramienta repack_bootimg podría usarse para reconstruir un boot-debug.img o vendor_boot-debug.img con la política GSI actualizada.

Reempaquetar un disco RAM de depuración

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

Los pasos son los siguientes:

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

Configure el entorno de ejecución para repack_bootimg :

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

Descargue userdebug_plat_sepolicy.cil o boot-with-debug-ramdisk-${KERNEL_VERSION}.img de la compilación GSI que está utilizando. Por ejemplo, si está utilizando 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 utilizar 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 GSI pasa a llamarse boot-with-debug-ramdisk-${KERNEL_VERSION}.img .

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.

Ruta de la política de depuración de usuarios

El 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 dentro de un disco ram 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 comando del kernel. De lo contrario, la ruta es userdebug_plat_sepolicy.cil .

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

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

A partir de Android 12, la ruta 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. La siguiente tabla muestra las rutas dentro de un disco RAM de depuración en diferentes versiones de Android.

Imagen de depuración	androide 10	androide 11	androide 12
Arranque GKI con disco ram de depuración-${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`
Proveedor específico del dispositivo_boot-debug.img	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 Android 11 a first_stage_ramdisk/userdebug_plat_sepolicy.cil dentro de 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

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 encadenada 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, es necesario 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 disco ram de depuración solo se puede usar cuando un dispositivo está desbloqueado, lo que permite imágenes firmadas con clave no liberada 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