Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Prueba de VTS con Debug Ramdisk

Dado que Android 10, la imagen de un sistema genérico (GSI) se utiliza para ejecutar CTS-en-GSI / STM pruebas de cumplimiento cambiado de depuración de usuario a usuario tipo de generación con el fin de ser comunicado firmado. Este es un problema para las pruebas VTS VTS porque requiere adb root de correr, pero adb root no está disponible en un dispositivo de usuario de construcción.

El (o la imagen de arranque de depuración) disco de memoria de depuración se introduce para permitir adb root en un dispositivo de usuario cuya acumulación gestor de arranque está desbloqueado . Esto simplifica el flujo de prueba utilizando el mismo usuario acumulación GSI system.img para el CTS-en-GSI y STM-en-GSI. Para la configuración STS, utilizando otro depuración de usuario OEM system.img sigue siendo necesaria.

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

Banco de pruebas Prueba con Construir Depurar ramdisk adb root? Android 9 -> 10 cambio de variante de compilación
CTS Sistema de OEM usuario norte norte Ningún cambio
CTS-en-GSI GSI usuario norte norte

userdebug -> usuario GSI

lanzamiento firmado

STS Sistema de OEM userdebug norte Y Nuevo en Q
VTS GSI usuario Y Y

userdebug -> usuario GSI

lanzamiento firmado

Visión general

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

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

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

Para núcleo genérico de imagen (GKI) el uso de dispositivos que tienen un vendor_boot partición, boot-debug.img no debe ser flasheado, como el boot partición debe ser flasheado una imagen de GKI certificado con. En lugar vendor_boot-debug.img debe dirigió a la vendor_boot partición con el fin de facilitar el disco de memoria de depuración.

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 tener firma de liberación y solo se puede usar si el dispositivo está desbloqueado.

El debug ramdisk no se generará ni se utilizará para actualizar dispositivos con:

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

Android 12 GSI

No se requieren instrucciones adicionales para usar debug ramdisk con Android 12 GSI.

A partir de 29/09/2021, discos RAM de depuración ya no requieren la actualización con el repack_bootimg herramienta. Android 12 GSI acumulación después de SGR1.210929.001 (7777720) incorpora la puesta al día userdebug_plat_sepolicy.cil archivo en su system.img e ignora userdebug_plat_sepolicy.cil del disco RAM de depuración. Ver las licencias obligatorias para obtener más detalles.

Android 11 GSI

Cuando el boot-debug.img o vendor_boot-debug.img se utiliza, el sistema de sepolicy se carga desde el userdebug_plat_sepolicy.cil archivo en el disco de memoria de depuración del boot-debug.img o vendor_boot-debug.img . Con el fin de arrancar las imágenes del GSI, por favor incorpore siempre cambios sepolicy-arriba-hasta la fecha de la android11-gsi rama de reconstruir su boot-debug.img o vendor_boot-debug.img .

Como alternativa, el repack_bootimg herramienta podría utilizarse para reconstruir un boot-debug.img o vendor_boot-debug.img con sepolicy GSI actualizada.

Reempaquetado de un ramdisk de depuración

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

Los pasos son los siguientes:

  1. Descargar otatools.zip de https://ci.android.com . Recomendamos la descarga desde los artefactos de construcción de aosp_arm64-userdebug en aosp-master .

  2. Configuración del entorno de ejecución para repack_bootimg :

    unzip otatools.zip -d otatools
    export PATH="${PWD}/otatools/bin:${PATH}"
    repack_bootimg --help
    
  3. Descargar el userdebug_plat_sepolicy.cil o boot-with-debug-ramdisk-${KERNEL_VERSION}.img de la acumulación GSI está utilizando. Por ejemplo, si está utilizando un arm64 GSI de RJR1.211020.001 (7840830) , a continuación, descarga de https://ci.android.com/builds/submitted/ 7840830 / aosp_arm64 usuario / última .

  4. Actualizar 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 de acuerdo con las configuraciones de los dispositivos. Consulte la siguiente sección para una explicación detallada.

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

Lo anterior repack_bootimg copias de archivos userdebug_plat_sepolicy.cil del disco RAM de --src_bootimg al disco de memoria 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, el camino es first_stage_ramdisk/userdebug_plat_sepolicy.cil para dispositivos con androidboot.force_normal_boot=1 en la línea de comandos del núcleo. De lo contrario, el camino es userdebug_plat_sepolicy.cil .

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

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

A partir de Android 12, la ruta de acceso dentro de un disco de memoria de depuración es siempre 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 Android 10 Android 11 Android 12
Arranque GKI con 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

Puede especificar --ramdisk_add para copiar archivos desde y hacia diferentes trayectorias con una lista de src_path:dst_path pares. Por ejemplo, el archivo siguiente comando copia first_stage_ramdisk/userdebug_plat_sepolicy.cil de un androide 11 boot-with-debug-ramdisk-5.4.img a first_stage_ramdisk/userdebug_plat_sepolicy.cil dentro de un androide 11 vendor_boot-debug.img .

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, a continuación, el comando debe ser ajustado de la siguiente manera 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 se pasa a --dst_bootimg se configura como un BAV-encadenado partición, un pie de AVB necesita ser añadido después de ejecutar el repack_bootimg comando.

Por ejemplo, antes de ejecutar repack_bootimg , ejecute el siguiente comando para comprobar 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, un pie de AVB necesita ser añadido después de ejecutar el repack_bootimg comando. El uso de cualquier tecla de prueba para firmar los vendor_boot-debug.img obras porque el disco de memoria de depuración sólo se puede utilizar cuando se desbloquea un dispositivo, lo que permite que las imágenes firmadas clave no liberación en el boot o vendor_boot partición.

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