Imágenes genéricas del sistema

Una imagen genérica del sistema (GSI) es una imagen del sistema con configuraciones ajustadas para dispositivos Android. Se considera una implementación pura de Android con código del Proyecto de código abierto de Android (AOSP) no modificado que cualquier dispositivo Android que ejecute Android 9 o superior puede ejecutarse correctamente.

Los GSI se utilizan para ejecutar pruebas VTS y CTS-on-GSI. La imagen del sistema de un dispositivo Android se reemplaza con un GSI y luego se prueba con Vendor Test Suite (VTS) y Compatibility Test Suite (CTS) para garantizar que el dispositivo implemente las interfaces del proveedor correctamente con la última versión de Android.

Para comenzar con GSI, revise las siguientes secciones para obtener detalles sobre las configuraciones de GSI (y las variaciones permitidas) y los tipos . Cuando esté listo para usar un GSI, descargue y cree el GSI para su dispositivo objetivo, luego actualice el GSI a un dispositivo Android.

Configuración y variaciones de GSI

El Android GSI actual tiene la siguiente configuración:

El GSI actual de Android incluye las siguientes variaciones principales:

  • Arquitectura de la CPU. Soporte para diferentes instrucciones de CPU (ARM, x86, etc.) y bits de CPU (32 bits o 64 bits).

Objetivos de GSI para las pruebas de cumplimiento de Treble

El GSI utilizado para las pruebas de cumplimiento está determinado por la versión de Android con la que se inicia el dispositivo.

Tipo de dispositivo Objetivo de construcción
Dispositivos que se inician con Android 12 gsi_$arch-user (Firmado)
Dispositivos que se inician con Android 11 gsi_$arch-user (Firmado)
Dispositivos que se inician con Android 10 gsi_$arch-user (Firmado)
Dispositivos que se inician con Android 9 gsi_$arch-userdebug

Todos los GSI se crean a partir del código base de Android 12 y cada arquitectura de CPU tiene un binario GSI correspondiente (consulte la lista de objetivos de compilación en Creación de GSI ).

Cambios en Android 12 GSI

Los dispositivos que se inician con Android 12 o se actualizan a él deben usar GSI de Android 12 para las pruebas de cumplimiento. Esto incluye los siguientes cambios importantes con respecto a GSI anteriores:

  • Nombre del objetivo. El nombre del objetivo GSI para las pruebas de cumplimiento se cambia a gsi_$arch . El GSI con nombre de destino aosp_$arch se conserva para los desarrolladores de aplicaciones de Android. El plan de prueba CTS-on-GSI también se reduce para probar la interfaz del proveedor.
  • El GSI heredado se eliminará gradualmente. GSI 12 elimina las soluciones alternativas que se adaptan a dispositivos Android 8.0 u 8.1 que no están completamente Treblizados.
  • Política SE de depuración de usuario. El GSI gsi_$arch contiene userdebug_plat_sepolicy.cil . Al actualizar el vendor_boot-debug.img o boot-debug.img específico del OEM, /system/bin/init cargará userdebug_plat_sepolicy.cil desde GSI system.img . Consulte Pruebas VTS con Debug Ramdisk para obtener más detalles.

Cambios en Android 11 GSI

Los dispositivos que se inician con Android 11 o se actualizan a él deben usar GSI de Android 11 para las pruebas de cumplimiento. Esto incluye los siguientes cambios importantes con respecto a GSI anteriores:

  • contenidos system_ext. Android 11 define una nueva partición system_ext . GSI coloca el contenido de la extensión del sistema en la carpeta system/system_ext .
  • APEX. GSI contiene APEX tanto aplanados como comprimidos. Cuál usar está determinado por la propiedad del sistema ro.apex.updatable en la partición del proveedor en tiempo de ejecución. Consulte Configuración del sistema para admitir actualizaciones de APEX para obtener más detalles.

Cambios en Android 10 GSI

Los dispositivos que se inician con Android 10 o se actualizan a él deben usar GSI de Android 10 para las pruebas de cumplimiento. Esto incluye los siguientes cambios importantes con respecto a GSI anteriores:

  • Construcción de usuario. GSI tiene una compilación de usuario de Android 10. En Android 10, la compilación de usuario GSI se puede utilizar en las pruebas de cumplimiento de CTS-on-GSI/VTS. Consulte Pruebas de VTS con Debug Ramdisk para obtener más detalles.
  • Formato sin distribuir. GSI con objetivos aosp_$arch se crean con formato no distribuido. Puede utilizar img2simg para convertir un GSI no distribuido a formato disperso si es necesario.
  • Sistema como raíz. El objetivo de compilación GSI heredado denominado aosp_$arch_a se había eliminado gradualmente. Para los dispositivos actualizados de Android 8 u 8.1 a Android 10 con ramdisk y sin sistema como raíz, use el GSI heredado aosp_$arch_ab . El init actualizado en ramdisk admite OEM system.img con diseño de sistema como raíz.
  • Verificar arranque. Usando GSI solo necesitas desbloquear el dispositivo. No es necesario desactivar la verificación de inicio.

Cambios en Android 9 GSI

Los dispositivos que se inician con Android 9 o se actualizan a él deben usar Android 9 GSI para las pruebas de cumplimiento. Esto incluye los siguientes cambios importantes con respecto a GSI anteriores:

  • Fusiona GSI y emulador. Los GSI se crean a partir de imágenes del sistema de productos emuladores, por ejemplo, aosp_arm64 y aosp_x86 .
  • Sistema como raíz. En versiones anteriores de Android, los dispositivos que no admitían actualizaciones A/B podían montar la imagen del sistema en el directorio /system . En Android 9, la raíz de la imagen del sistema se monta como la raíz del dispositivo.
  • Interfaz de carpeta de 64 bits. En Android 8.x, los GSI de 32 bits usaban la interfaz de carpeta de 32 bits. Android 9 no es compatible con la interfaz de carpeta de 32 bits, por lo que tanto los GSI de 32 bits como los de 64 bits utilizan la interfaz de carpeta de 64 bits.
  • Aplicación de VNDK. En Android 8.1, VNDK era opcional. A partir de Android 9, VNDK es obligatorio, por lo que se debe configurar BOARD_VNDK_VERSION .
  • Propiedad del sistema compatible. Android 9 habilita la verificación de acceso a una propiedad del sistema compatible ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Cambios en Keymaster de Android 9

En versiones anteriores de Android, los dispositivos que implementaban Keymaster 3 o inferior debían verificar que la información de la versión ( ro.build.version.release y ro.build.version.security_patch ) reportada por el sistema en ejecución coincidiera con la información de la versión reportada por el gestor de arranque. Esta información normalmente se obtenía del encabezado de la imagen de inicio.

En Android 9 y versiones posteriores, este requisito cambió para permitir a los proveedores iniciar un GSI. Específicamente, Keymaster no debería realizar la verificación porque la información de la versión reportada por GSI puede no coincidir con la información de la versión reportada por el gestor de arranque del proveedor. Para los dispositivos que implementan Keymaster 3 o inferior, los proveedores deben modificar la implementación de Keymaster para omitir la verificación (o actualizar a Keymaster 4). Para obtener más información sobre Keymaster, consulte Almacén de claves respaldado por hardware .

Descargar GSI

Puede descargar GSI prediseñados desde el sitio web de integración continua (CI) de AOSP en ci.android.com . Si el tipo de GSI para su plataforma de hardware no está disponible para descargar, consulte la siguiente sección para obtener detalles sobre cómo crear GSI para objetivos específicos.

Construir GSI

A partir de Android 9, cada versión de Android tiene una rama GSI llamada DESSERT -gsi en AOSP (por ejemplo, android12-gsi es la rama GSI en Android 12). Las sucursales de GSI incluyen el contenido de Android con todos los parches de seguridad y parches de GSI aplicados.

Para crear un GSI, configure el árbol de fuentes de Android descargándolo desde una rama de GSI y eligiendo un destino de compilación de GSI . Utilice las tablas de destino de compilación a continuación para determinar la versión GSI correcta para su dispositivo. Una vez completada la compilación, GSI es la imagen del sistema (es decir, system.img ) y aparece en la carpeta de salida out/target/product/ generic_arm64 .

Por ejemplo, para compilar el objetivo de compilación GSI gsi_arm64-userdebug en la rama GSI android12-gsi , ejecute los siguientes comandos.

$ repo init -u https://android.googlesource.com/platform/manifest -b android12-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch gsi_arm64-userdebug
$ make -j4

Objetivos de compilación de Android GSI

Los siguientes objetivos de compilación de GSI son para dispositivos que se inician con Android 9 o superior.

Nombre GSI arco de CPU Bits de la interfaz de carpeta Sistema como raíz Objetivo de construcción
gsi_arm BRAZO 64 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 Y gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Y gsi_x86_64-user
gsi_x86_64-userdebug

Requisitos para flashear GSI

Los dispositivos Android pueden tener diferentes diseños, por lo que no existe un comando genérico ni un conjunto de instrucciones para actualizar un GSI que se aplique a todos los dispositivos. Consulte con el fabricante del dispositivo Android para obtener instrucciones explícitas de actualización. Utilice los siguientes pasos como guía general:

  1. Asegúrese de que el dispositivo tenga lo siguiente:
    • treblizado
    • Un método para desbloquear dispositivos (para que puedan actualizarse usando fastboot )
    • Un estado desbloqueado para que se pueda actualizar a través de fastboot (para asegurarse de tener la última versión de fastboot , compílelo desde el árbol de fuentes de Android).
  2. Borre la partición actual del sistema, luego actualice el GSI a la partición del sistema.
  3. Borre los datos del usuario y borre los datos de otras particiones necesarias (por ejemplo, datos del usuario y particiones del sistema).
  4. Reinicie el dispositivo.

Por ejemplo, para actualizar un GSI a cualquier dispositivo Pixel:

  1. Inicie en modo fastboot y desbloquee el gestor de arranque .
  2. Los dispositivos que admiten fastbootd también deben iniciarse en fastbootd mediante:
    $ fastboot reboot fastboot
  3. Borre y actualice el GSI a la partición del sistema:
    $ fastboot erase system
$ fastboot flash system system.img
  4. Borre los datos del usuario y borre los datos de otras particiones necesarias (por ejemplo, datos del usuario y particiones del sistema):
    $ fastboot -w
  5. Reiniciar:
    $ fastboot reboot
En dispositivos Android 10 o más nuevos que tienen particiones del sistema más pequeñas, puede aparecer el siguiente mensaje de error al actualizar el GSI:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Utilice el siguiente comando para eliminar la partición del producto y liberar espacio para la partición del sistema. Esto proporciona espacio adicional para actualizar el GSI:
$ fastboot delete-logical-partition product_a
El sufijo _a debe coincidir con el ID de ranura de la partición del sistema, como system_a en este ejemplo.

Contribuir a GSI

Android agradece sus contribuciones al desarrollo de GSI. Puede participar y ayudar a mejorar el GSI de la siguiente manera:

  • Creando un parche GSI. DESSERT -gsi no es una rama de desarrollo y solo acepta selecciones de la rama principal de AOSP, por lo que para enviar un parche GSI, debe:
    1. Envíe el parche a la rama main de AOSP .
    2. Elija el parche para DESSERT -gsi .
    3. Presente un error para que se revise la selección.
  • Informar errores de GSI o hacer otras sugerencias. Revise las instrucciones en Informar de errores y luego busque o archive errores de GSI .

Consejos

Cambiar el modo de la barra de navegación usando adb

Al arrancar con GSI, el modo de la barra de navegación se configura mediante la anulación del proveedor. Puede cambiar el modo de la barra de navegación ejecutando el siguiente comando adb en tiempo de ejecución.

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

Donde mode puede ser threebutton , twobutton , gestural , etc.