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. La imagen del sistema de un dispositivo Android se reemplaza por una GSI y, luego, se prueba con el Conjunto de pruebas del proveedor (VTS) y el Conjunto 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 la configuración de la 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 según tu orientación por dispositivo y, luego, instálala en un dispositivo Android.

Configuración de la 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 la 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 en 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 la 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 tiene la 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, de ser necesario.
System-as-root. Se eliminó gradualmente el objetivo de compilación de la GSI heredada de nombre aosp_$arch_a. Para los dispositivos que se actualicen 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 mediante CTS en GSI, usa los objetivos de compilación de la GSI de Android.

GSI heredada

Son las GSI heredadas que llevan el sufijo _ab en el 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 mediante CTS en GSI, usa los objetivos de compilación de la GSI heredada.

Cambios de la GSI de Android 9

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

Fusión de la GSI y el 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, se monta la raíz de la imagen del sistema 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, se obtenía esta información a partir del encabezado de la imagen de inicio.

En Android 9 y versiones posteriores, se modificó este requisito a fin de permitir que los proveedores pudieran iniciar una GSI. Específicamente, Keymaster no debería verificar la plataforma, ya que los datos de la versión que informa la GSI podrían no coincidir con los 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 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 usadas para compilar el dispositivo. En la siguiente tabla, se resume la compatibilidad de la GSI heredada con los dispositivos actualizados.

Caso de uso	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	Sí
3	10	`current`	10	Sí

El caso práctico admitido más común es el n.º 2, en el que las GSI heredadas admiten dispositivos que ejecutan Android 8.1 compilados 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 se omite BOARD_VNDK_VERSION de la compilación. Estos dispositivos no son compatibles porque los objetos binarios de su 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
Has una portabilidad o actualiza los objetos binarios del proveedor para que dependan de las bibliotecas compartidas a partir de Android 10 (caso práctico n.º 3).

Nota: Solo se puede habilitar BOARD_VNDK_RUNTIME_DISABLE con fines de prueba al mismo tiempo que se habilita BOARD_VNDK_VERSION. NO se debe activar durante la compilación de la imagen de producción.

Cómo descargar GSI

Puedes descargar GSI compiladas previamente desde el sitio web de integración continua (CI) del AOSP en ci.android.com. Si el tipo de GSI según 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 en función de objetivos específicos.

Cómo compilar GSI

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

Para configurar el árbol de fuentes de Android y compilar una GSI, realiza la descarga desde una rama de GSI y elige un objetivo de compilación de la GSI. Usa las tablas de objetivo de compilación que se incluyen a continuación para determinar la versión de GSI correcta según el dispositivo. Una vez que se completa la compilación, la GSI se convierte 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 vbmeta.img como salida, 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 la 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 la GSI son para 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 pensados para 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`

Requisitos para escribir las GSI en la memoria flash

Los dispositivos Android pueden tener diferentes diseños, de manera que no hay un comando genérico ni un conjunto de instrucciones para instalar una GSI que se aplique a todos los dispositivos. Comunícate con el fabricante del dispositivo Android para obtener instrucciones de instalación específicas. Sigue estos pasos como instrucciones generales:

Asegúrate de que el dispositivo cuente con lo siguiente:
- Treble
- Un método para desbloquear dispositivos (de manera que se puedan escribir en la memoria flash mediante fastboot)
- Un método para inhabilitar el inicio verificado (por ejemplo, vboot 1.0 o AVB)
- Un estado desbloqueado a fin de que se pueda instalar mediante fastboot (para asegurarte de tener la versión más reciente de fastboot, compila desde el árbol de fuentes de Android)
Inhabilita el inicio verificado.
Borra la partición del sistema actual y, luego, instala la GSI en la partición del sistema.
Limpia los datos del usuario y borra los datos de otras particiones necesarias (por ejemplo, las particiones del sistema y los datos del usuario).
Reinicia el dispositivo.

Por ejemplo, para instalar una GSI en cualquier dispositivo Pixel, haz lo siguiente:

Inicia el dispositivo en el modo fastboot y desbloquea el bootloader. Instala vbmeta.img para inhabilitar el inicio verificado (AVB):
```
$ fastboot --disable-verification flash vbmeta vbmeta.img
```
Los dispositivos que admiten fastbootd también deben iniciarse en fastbootd de la siguiente manera:
```
$ fastboot reboot fastboot
```

Borra e instala la GSI en la partición del sistema:

$ fastboot erase system
$ fastboot flash system system.img

Limpia los datos del usuario y borra los datos de otras particiones necesarias (por ejemplo, las particiones del sistema y los datos del usuario):
```
$ fastboot -w
```
Reinicia:
```
$ fastboot reboot
```

En los dispositivos con Android 10 que tienen particiones del sistema más pequeñas, puede aparecer el siguiente mensaje de error cuando se instala la GSI:

    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed

Usa el siguiente comando a fin de borrar la partición del producto y liberar espacio para la partición del sistema. De esta manera, liberarás espacio adicional para instalar la GSI:

$ fastboot delete-logical-partition product_a

El postfijo _a debe coincidir con el ID de la ranura de la partición del sistema, como system_a en este ejemplo.

Cómo contribuir a las GSI

Android agradece tus contribuciones para el desarrollo de GSI. Si quieres ayudar a mejorar la GSI, puedes hacer lo siguiente:

Crear un parche de GSI. DESSERT-gsi no es una rama de desarrollo y solo acepta los mejores elementos de la rama principal del AOSP. Por lo tanto, para enviar un parche de GSI, debes hacer lo siguiente:
1. Envía el parche a la rama master del AOSP.
2. Selecciona los mejores elementos del parche para DESSERT-gsi.
3. Presenta un error para que se revise la selección de los mejores elementos.
Informar errores de GSI o hacer otras sugerencias. Consulta las instrucciones en Cómo informar errores y, luego, explora o informa errores de la GSI.

Sugerencias

Cuando se inicia con GSI, el modo de la barra de navegación se configura mediante la anulación del proveedor. Puedes cambiar el modo de barra de navegación si ejecutas el siguiente comando adb en el entorno de ejecución.

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

mode puede ser threebutton, twobutton, gestural, etc.