Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Prueba de VTS con Debug Ramdisk

En Android 10, la imagen genérica del sistema (GSI) que se usa para ejecutar las pruebas de cumplimiento de CTS-on-GSI / VTS cambia de userdebug al tipo de compilación del usuario, porque GSI tiene firma de lanzamiento. Sin embargo, el comando adb root que otorga permisos de raíz de host al dispositivo Android bajo prueba no está disponible en una compilación de usuario. Esto es un problema porque VTS requiere adb root para ejecutarse.

El debug ramdisk se introduce en Android 10 para hacer posible adb root , si el dispositivo está desbloqueado. Esto simplifica el flujo de pruebas al reutilizar el mismo sistema GSI system.img . Para la configuración de STS, todavía se requiere el uso de otro userdebug OEM system.img . La siguiente tabla muestra imágenes y tipos 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

Ramdisk de depuración de arranque del proveedor

A partir de Android 11, vendor_boot-debug.img debe vendor_boot-debug.img en la partición /vendor_boot en VTS para dispositivos compatibles con la arquitectura de imagen de kernel genérica (GKI) . Y un boot-${KERNEL_VERSION}.img GKI firmado boot-${KERNEL_VERSION}.img debería ser flasheado en la partición /boot lugar de un boot-debug-{KERNEL_VERSION}.img .

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 se debe firmar la publicació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 verdadero
  • skip_initramfs en la línea de comandos del kernel

Cuando usa boot-debug.img , la boot-debug.img sistema ( plat_sepolicy.cil ) se carga desde boot-debug.img . Siempre incorpore nuevos cambios de política de seguridad de las ramas de android {N} -gsi para reconstruir boot-debug.img , por ejemplo, android11-gsi . De lo contrario, es posible que el dispositivo no pueda iniciar una nueva imagen GSI. Esto también se aplica a vendor_boot-debug.img para dispositivos que tienen una partición /vendor_boot .

Reempaquetado de un ramdisk de depuración

En lugar de incorporar cambios de sepolicy para reconstruir boot-debug.img , los socios pueden usar repack_bootimg para actualizar el archivo sepolicy en boot-debug.img (o vendor_boot-debug.img si el dispositivo usa un boot.img genérico).

Los pasos son los siguientes:

  1. Descargue otatools.zip desde https://ci.android.com . Por ejemplo, descárguelo de aosp_arm64-userdebug build artifacts.

  2. Ejecute el siguiente comando para comprobar que repack_bootimg está disponible.

    $ unzip otatools.zip -d otatools
    $ export PATH="$PWD"/otatools/bin:"$PATH"
    $ repack_bootimg
    
  3. Descargue un boot-debug.img genérico boot-debug.img de GSI. Por ejemplo, si utiliza un system.img genérico de RJR1.210330.001_7244771 , descargue el boot-debug-${KERNEL_VERSION}.img genérico boot-debug-${KERNEL_VERSION}.img de la misma versión RJR1.210330.001_7244771 .

  4. Ejecute el siguiente comando para extraer el archivo userdebug sepolicy de boot-debug-${KERNEL_VERSION}.img y actualícelo en el boot-debug.img específico boot-debug.img (o vendor_boot-debug.img ).

    $ repack_bootimg --src_bootimg boot-debug-5.4.img --dst_bootimg boot-debug.img
    $ repack_bootimg --src_bootimg boot-debug-5.4.img --dst_bootimg vendor_boot-debug.img
    

La ruta de la política de depuración de usuarios

El repack_bootimg anterior copia el archivo /userdebug_plat_sepolicy.cil del /userdebug_plat_sepolicy.cil ram de --src_bootimg al --src_bootimg ram 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 comando del kernel. De lo contrario, la ruta es /userdebug_plat_sepolicy .

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 ramdisk de depuración es siempre /userdebug_plat_sepolicy , 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
Depuración de arranque de GKI: {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 ubicaciones, con una lista de pares src_path: dst_path. La opción --help también ofrece más ejemplos.

$ repack_bootimg \
    --src_bootimg boot-debug-5.4.img \
    --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil

$ repack_bootimg --help

Cambios de AOSP

Los cambios de debug ramdisk en AOSP se identifican mediante el hashtag debug_ramdisk .

Estos archivos de imagen adicionales se generan en la carpeta de compilación out/target/product/$(TARGET_DEVICE) :

  • ramdisk-debug.img
  • boot-debug.img

Cuando boot-debug.img se 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 el usuario build system.img (ya sea de GSI o de OEM).

Esto también se aplica a dispositivos con vendor_boot-debug.img flasheado en la partición vendor_boot . es decir, los archivos de depuración se pueden cargar desde la partición /boot o /vendor_boot .