Imágenes genéricas del sistema

Una imagen genérica del sistema (GSI) es una imagen del sistema con configuraciones adaptadas para dispositivos Android. Se considera una implementación de Android pura con código del Proyecto de código abierto de Android (AOSP) sin modificar que cualquier dispositivo con Android 8.1 o versiones posteriores puede ejecutar correctamente.

Se usan las GSI para ejecutar pruebas de VTS y CTS en GSI. Se reemplaza la imagen del sistema de un dispositivo Android con una GSI y, luego, se prueba con el Paquete de pruebas del proveedor (VTS) y el Paquete de pruebas de compatibilidad (CTS) a fin de garantizar que el dispositivo implemente las interfaces del proveedor correctamente con la versión más reciente de Android.

Para comenzar a usar las GSI, consulta las siguientes secciones a fin de conocer los detalles sobre las configuraciones de GSI (y las variantes permitidas), los tipos (GSI de Android y GSI heredada) y las dependencias de VNDK y los objetos binarios del proveedor. Cuando estés listo para usar una GSI, descarga y compila la GSI para tu orientación por dispositivo y, luego, instala la GSI en un dispositivo Android.

Configuración de GSI y variantes

La GSI actual de Android tiene la siguiente configuración:

  • Treble: La GSI es totalmente compatible con los cambios arquitectónicos basados en HIDL (también conocidos como Treble) que se agregaron en Android 8.0, incluida la compatibilidad con interfaces HIDL. Puedes usar la GSI en cualquier dispositivo Android que use interfaces HIDL del proveedor. (Para obtener más detalles, consulta Recursos de la arquitectura.)
  • Inicio verificado. La GSI no incluye una solución de inicio verificado (como vboot 1.0 o AVB). A fin de instalar la GSI en un dispositivo con Android 9 o versiones anteriores, el dispositivo debe tener un método para inhabilitar el inicio verificado.
  • Sistema de archivos: La GSI usa el sistema de archivos ext4.
  • Diseño de partición. La GSI usa el diseño de partición system-as-root.

La GSI actual de Android incluye las siguientes variantes principales:

  • Arquitectura de la CPU: Compatibilidad con diferentes instrucciones de CPU (ARM, x86, etc.) y valores de bits de CPU (32 bits o 64 bits).

Objetivos de GSI para pruebas de cumplimiento de Treble

La versión de Android con la que se lanza el dispositivo determina la GSI que se utiliza para las pruebas de cumplimiento.

Tipo de dispositivo Objetivo de compilación
Dispositivos que se lanzan con Android 10 aosp_$arch-user
Dispositivos que se lanzan con Android 9 aosp_$arch-userdebug
Dispositivos que se lanzan con Android 8.0 o Android 8.1 aosp_$arch_ab-userdebug

Todas las GSI se compilan a partir de la base de código de Android 10 y cada arquitectura de CPU tiene un objeto binario de GSI correspondiente (consulta la lista de objetivos de compilación en Cómo compilar GSI).

Cambios de GSI de Android 10

Los dispositivos que se lanzan con Android 10 deben usar las GSI de Android 10 para las pruebas de cumplimiento. Esto incluye los siguientes cambios importantes respecto de las GSI anteriores:

  • Compilación del usuario: La GSI ofrece compilación del usuario de Android 10. En Android 10, se puede usar la GSI de compilación del usuario en pruebas de cumplimiento de CTS en GSI/VTS. Consulta Cómo evaluar el VTS con ramdisk de depuración para obtener más información.
  • Formato sin dispersión: Las GSI con objetivo aosp_$arch se crean con un formato sin dispersión. Puedes usar img2simg para convertir una GSI sin dispersión a un formato disperso, si es necesario.
  • System-as-root: Se eliminó gradualmente el objetivo de compilación de GSI heredada de nombre aosp_$arch_a. Para los dispositivos que se actualizan de Android 8/8.1 a Android 10 con ramdisk y que no sean del tipo system-as-root, usa la GSI heredada aosp_$arch_ab. El init actualizado en ramdisk admite el system.img de OEM con el diseño de tipo system-as-root.

Para probar dispositivos que se lanzan con Android 9 o Android 10 con CTS en GSI, usa los objetivos de compilación de GSI de Android.

GSI heredada

Son las GSI heredadas que llevan el sufijo _ab en su nombre (por ejemplo, aosp_arm64_ab). Estas GSI se compilan a partir del árbol de fuentes de Android 10, pero contienen las siguientes configuraciones retrocompatibles para dispositivos actualizados desde Android 8/8.1:

  • Espacio de usuario de 32 bits + interfaz de Binder de 32 bits. Las GSI de 32 bits pueden seguir usando la interfaz de Binder de 32 bits
  • VNDK 8.1. Los dispositivos pueden usar el VNDK 8.1 incluido.
  • Montaje de directorios. Algunos dispositivos heredados usan directorios como puntos de montaje (por ejemplo, /bluetooth, /firmware/radio y /persist).

Para probar dispositivos que se lanzan con Android 8/8.1 con CTS en-GSI, usa los objetivos de compilación de la GSI heredada.

Cambios de GSI de Android 9

Las GSI de Android 9 incluyen los siguientes cambios importantes respecto de las GSI anteriores:

  • Fusión de GSI y emulador: Las GSI se compilan a partir de imágenes del sistema de productos de emulador, por ejemplo, aosp_arm64 y aosp_x86.
  • System-as-root. En las 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 Binder de 64 bits. En Android 8.x, las GSI de 32 bits usaban la interfaz de Binder de 32 bits. Android 9 no admite la interfaz de Binder de 32 bits, de manera que tanto las GSI de 32 bits como las de 64 bits usan la interfaz de Binder 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 para una propiedad del sistema compatible (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Cambios de Keymaster en Android 9

En las versiones anteriores de Android, los dispositivos que implementaban Keymaster 3 o versiones anteriores debían verificar que los datos de la versión (ro.build.version.release y ro.build.version.security_patch) informados por el sistema en ejecución coincidieran con los datos de la versión informados por el bootloader. Por lo general, esta información se obtenía a partir del encabezado de la imagen de inicio.

En Android 9 y versiones posteriores, este requisito cambió a fin de permitir que los proveedores pudieran iniciar como una GSI. Específicamente, Keymaster no debe verificar la plataforma, ya que los datos de la versión que informa la GSI podrían no coincidir con los datos de la versión que informa el bootloader del proveedor. En el caso de los dispositivos que implementan Keymaster 3 o versiones anteriores, los proveedores deben modificar la implementación de Keymaster a fin de omitir la verificación (o actualizar a Keymaster 4). Si deseas obtener más información sobre Keymaster, consulta el almacén de claves con copia de seguridad en hardware.

Objetos binarios del proveedor y dependencias de VNDK

Los dispositivos que actualizan a Android 10 tienen rutas de actualización diferentes según la versión de los objetos binarios de proveedor que estén en uso en el dispositivo y las configuraciones relacionadas con VNDK que se utilicen para compilar el dispositivo. En la siguiente tabla, se resume la compatibilidad de GSI heredada con los dispositivos actualizados.

Caso práctico Versión de
objetos binarios
del proveedor
BOARD_VNDK_VERSION Versión de objetos binarios del sistema
de la GSI heredada
Compatibilidad con GSI heredada
0 8.0 (cualquiera) 10 No
1 8.1 (vacío) 10 No
2 8.1 current 10
3 10 current 10

El caso práctico admitido más común es el n.º 2, en el que las GSI heredadas admiten los dispositivos con Android 8.1 que se compilaron con el objeto BOARD_VNDK_VERSION establecido en current.

El caso n.º 1 no es compatible. En este caso, las GSI heredadas NO admiten los dispositivos con Android 8.1 en los que BOARD_VNDK_VERSION se omite de la compilación. Estos dispositivos no son compatibles porque sus objetos binarios del proveedor dependen de bibliotecas compartidas de Android 8.1 que no son de VNDK, las cuales no están incluidas en las GSI heredadas. Para hacer que estos dispositivos sean compatibles con una GSI heredada, debes realizar una de las siguientes acciones:

  • Habilita BOARD_VNDK_VERSION sin BOARD_VNDK_RUNTIME_DISABLE (caso práctico n.º 2).

    O

  • Transmite o actualiza los objetos binarios del proveedor para que dependan de las bibliotecas compartidas a partir de Android 10 (caso práctico n.º 3).

Cómo descargar GSI

Puede descargar GSI compiladas previamente desde el sitio web de integración continua (CI) de AOSP en ci.android.com. Si el tipo de GSI para tu plataforma de hardware no está disponible para descargar, consulta la siguiente sección a fin de obtener información sobre cómo compilar GSI para objetivos específicos.

Cómo compilar GSI

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

Para compilar una GSI, configura el árbol de fuentes de Android. Para ello, descarga desde una rama de GSI y elige un objetivo de compilación de GSI. Usa las tablas de objetivo de compilación a continuación para determinar la versión de GSI correcta para tu dispositivo. Una vez que se completa la compilación, se convierte la GSI en la imagen del sistema (es decir, system.img) y aparece en out/target/product/generic_arm64 de la carpeta de salida. La compilación también genera como resultado vbmeta.img, que puedes usar para inhabilitar el inicio verificado en los dispositivos que usan el inicio verificado de Android.

Por ejemplo, para compilar el aosp_arm64-userdebug del objetivo de compilación de la GSI en el android10-gsi de la rama de GSI, ejecuta los siguientes comandos:

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

Objetivos de compilación de la GSI de Android

Los siguientes objetivos de compilación de GSI están destinados a los dispositivos que se lanzan con Android 9 o versiones posteriores. Debido a una reducción de variantes entre las arquitecturas, Android 10 solo incluye cuatro productos de GSI.

Nombre de la GSI Arco de la CPU Valor de bits de la interfaz de Binder System-as-root Objetivo de compilación
aosp_arm ARM 64 S aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 S aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 x86 64 S aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 S aosp_x86_64-user
aosp_x86_64-userdebug

Objetivos de compilación de la GSI heredada

Los siguientes objetivos de compilación de la GSI heredada están destinados a los dispositivos que se actualizan de Android 8.0/8.1 a Android 10. Los nombres de la GSI heredada incluyen el sufijo _ab para que sea posible distinguirlos de los nombres de la GSI de Android 10.

Nombre de la GSI Arco de la CPU Valor de bits de la interfaz de Binder System-as-root Objetivo de compilación
aosp_arm_ab ARM 32 S aosp_arm_ab-userdebug
aosp_arm_64b_ab ARM 64 S aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 S aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 S aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 S aosp_x86_64_ab-userdebug