Se usó la API de Cloud Translation para traducir esta página.

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) sin modificar que cualquier dispositivo Android con Android 9 o superior puede ejecutar 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 los GSI, revise las siguientes secciones para obtener detalles sobre las configuraciones (y las variaciones permitidas) y tipos de GSI. 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:

Triplicar. El GSI incluye soporte completo para los cambios arquitectónicos basados en AIDL/HIDL (también conocidos como Treble ), incluido el soporte para las interfaces AIDL e HIDL . Puede usar el GSI en cualquier dispositivo Android que use interfaces de proveedores AIDL/HIDL. (Para obtener más detalles, consulte Recursos de arquitectura ).
Sistema de archivos. El GSI utiliza el sistema de archivos ext4.

El GSI de Android actual incluye las siguientes variaciones importantes:

arquitectura de la CPU. Compatibilidad con 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 compilación
Dispositivos que se lanzan con Android 12	`gsi_$arch-user` (Firmado)
Dispositivos que se lanzan con Android 11	`gsi_$arch-user` (Firmado)
Dispositivos que se lanzan con Android 10	`gsi_$arch-user` (Firmado)
Dispositivos que se lanzan 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 la GSI de Android 12

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

Nombre de destino. El nombre de destino de GSI para las pruebas de cumplimiento se cambia a gsi_$arch . El GSI con el nombre de destino aosp_$arch se mantiene 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 elimina gradualmente. GSI 12 elimina las soluciones alternativas que acomodan dispositivos Android 8.0 u 8.1 que no están completamente Treblizados.
SEPolicy de depuración de usuario. El GSI gsi_$arch contiene userdebug_plat_sepolicy.cil . Al vendor_boot-debug.img o boot-debug.img específico del OEM, /system/bin/init cargará userdebug_plat_sepolicy.cil desde el system.img de GSI. Consulte Pruebas de VTS con Debug Ramdisk para obtener más detalles.

Cambios en la GSI de Android 11

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

contenido 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 aplanados y 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 los detalles.

Cambios en la GSI de Android 10

Los dispositivos que se inicien con Android 10 o se actualicen a Android 10 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 usar en las pruebas de cumplimiento de CTS-on-GSI/VTS. Consulte Pruebas de VTS con Debug Ramdisk para obtener más información.
Formato no disperso. Los GSI con objetivos aosp_$arch se construyen con un formato no disperso. Puede usar img2simg para convertir un GSI no disperso a un formato disperso si es necesario.
Sistema como raíz. El objetivo de compilación de GSI heredado llamado aosp_$arch_a se eliminó 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 es compatible con OEM system.img con diseño de sistema como raíz.
Verificar arranque. Usando GSI solo necesita desbloquear el dispositivo. No es necesario deshabilitar la verificación de arranque.

Cambios en la GSI de Android 9

Los dispositivos que se inicien con Android 9 o se actualicen a Android 9 deben usar GSI de Android 9 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 las 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 enlace de 32 bits. Android 9 no es compatible con la interfaz de enlace de 32 bits, por lo que tanto los GSI de 32 bits como los GSI de 64 bits usan la interfaz de enlace de 64 bits.
Cumplimiento 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 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 ) informada por el sistema en ejecución coincidiera con la información de la versión informada por el gestor de arranque. Dicha información generalmente se obtenía del encabezado de la imagen de arranque.

En Android 9 y versiones posteriores, este requisito cambió para permitir que los proveedores inicien un GSI. Específicamente, Keymaster no debe realizar la verificación porque la información de la versión informada por GSI puede no coincidir con la información de la versión informada 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 .

Descarga de GSI

Puede descargar GSI preconstruidos 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.

Creación de GSI

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

Para compilar un GSI, configure el árbol de fuentes de Android descargándolo desde una sucursal 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, el 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 destino de compilación de GSI gsi_arm64-userdebug en la rama de 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 en Android 9 o superior.

nombre GSI	arco de la CPU	Bitness de la interfaz del aglutinante	Sistema como raíz	Objetivo de compilació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 hay un comando genérico o 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 de actualización explícitas. Use los siguientes pasos como una guía general:

Asegúrese de que el dispositivo tenga lo siguiente:
- triplicado
- Un método para desbloquear dispositivos (para que puedan ser flasheados usando fastboot )
- Un estado desbloqueado para que se pueda flashear a través fastboot (para asegurarse de que tiene la última versión de fastboot , constrúyala desde el árbol de fuentes de Android).
Borre la partición del sistema actual, luego actualice el GSI en la partición del sistema.
Limpie los datos de usuario y borre los datos de otras particiones necesarias (por ejemplo, datos de usuario y particiones del sistema).
Reinicie el dispositivo.

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

Inicie en modo fastboot y desbloquee el gestor de arranque .
Los dispositivos que admiten fastbootd también deben iniciarse en fastbootd mediante:
```
$ fastboot reboot fastboot
```

Borre y actualice el GSI en la partición del sistema:

$ fastboot erase system
$ fastboot flash system system.img

Limpie los datos de usuario y borre los datos de otras particiones necesarias (por ejemplo, datos de usuario y particiones del sistema):
```
$ fastboot -w
```
Reiniciar:
```
$ fastboot reboot
```

En Android 10 o dispositivos más nuevos que tienen particiones de 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

Use 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 la identificación de la ranura de la partición del sistema, como system_a en este ejemplo.

Contribuyendo a GSI

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

Creación de un parche GSI. DESSERT -gsi no es una rama de desarrollo y solo acepta selecciones selectivas de la rama principal de AOSP, por lo que para enviar un parche de GSI, debe:
1. Envíe el parche a la sucursal master de AOSP .
2. Elija el parche para DESSERT -gsi .
3. Presenta un error para que se revise el cherrypick.
Informar errores de GSI o hacer otras sugerencias. Revise las instrucciones en Informe de errores , luego explore o presente los errores de GSI .

Consejos

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 el mode puede ser de threebutton botones, twobutton , gestural , etc.