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 9 o versiones posteriores puede ejecutar correctamente.

Las GSI se usan para ejecutar pruebas de VTS y CTS en la 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) para 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) y los tipos. Cuando quieras usar una GSI, descárgala y compílala según tu segmentació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 AIDL/HIDL (también conocidos como Treble), lo que incluye la compatibilidad con interfaces AIDL y HIDL. Puedes usar la GSI en cualquier dispositivo Android que use interfaces AIDL/HID del proveedor (para obtener más detalles, consulta los Recursos de la arquitectura).
• Sistema de archivos. La GSI usa el sistema de archivos ext4.

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.

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

Cambios de GSI de Android 12

Los dispositivos que se lanzan con Android 12 o se actualizan a esa versión deben usar las GSI de Android 12 para las pruebas de cumplimiento. Esto incluye los siguientes cambios importantes respecto de las GSI anteriores:

• Nombre del destino. Se cambió el nombre del objetivo de la GSI para las pruebas de cumplimiento con gsi_$arch. Se mantiene la GSI con el nombre de destino aosp_$arch para los desarrolladores de apps para Android. El plan de prueba CTS-on-GSI también se reduce para probar la interfaz del proveedor.
• Las GSI heredadas se eliminan de manera gradual: GSI 12 quita las soluciones alternativas para dispositivos Android 8.0 y 8.1 que aún no adoptaron por completo Treble.
• Userdebug SEPolicy. La GSI gsi_$arch contiene userdebug_plat_sepolicy.cil. Cuando se instala la vendor_boot-debug.img o la boot-debug.img específica del OEM, /system/bin/init cargará userdebug_plat_sepolicy.cil desde GSI system.img. Consulta el artículo para evaluar el VTS con ramdisk de depuración para obtener más información.

Cambios de GSI de Android 11

Los dispositivos que se lanzan con Android 11 o se actualizan a dicha versión deben usar las GSI de Android 11 para las pruebas de cumplimiento. Esto incluye los siguientes cambios importantes respecto de las GSI anteriores:

• Contenidos system_ext. Android 11 define una partición system_ext nueva. La GSI coloca el contenido de la extensión del sistema en la carpeta system/system_ext.
• APEX. La GSI contiene APEX planos y comprimidos. La propiedad del sistema ro.apex.updatable determina cuál usar en la participación del proveedor al momento de la ejecución. Consulta los detalles en el artículo sobre configuración del sistema para que admita actualizaciones de APEX.

Cambios de GSI de Android 10

Los dispositivos que se lanzan con Android 10 o se actualizan a dicha versión 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 los detalles en el artículo para evaluar el VTS con ramdisk de depuració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.
• Inicio verificado. Para usar la GSI, solo debes desbloquear el dispositivo. No es necesario inhabilitar el inicio verificado.

Cambios de GSI de Android 9

Los dispositivos que se lanzan con Android 9 o se actualizan a esa versión deben usar las GSI de Android 9 para las pruebas de cumplimiento. Esto incluye 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, 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 para 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.

Cómo descargar GSIs

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 para 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, android12-gsi es la rama de la GSI en Android 12). 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.

Por ejemplo, para compilar el gsi_arm64-userdebug del objetivo de compilación de la GSI en el android12-gsi de la rama de la GSI, ejecuta 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 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.

Requisitos para instalar GSI

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:

1. 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 estado desbloqueado para que se pueda escribir en la memoria flash mediante fastboot (para asegurarte de tener la versión más reciente de fastboot, compila desde el árbol de fuentes de Android)
2. Borra la partición del sistema actual y, luego, instala la GSI en la partición del sistema.
3. Limpia los datos del usuario y borra los datos de otras particiones necesarias (por ejemplo, las particiones del sistema y los datos del usuario).
4. Reinicia el dispositivo.

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

1. Inicia el dispositivo en el modo fastboot y desbloquea el bootloader.
2. Los dispositivos que admiten fastbootd también deben iniciarse en fastbootd de la siguiente manera:

   $ fastboot reboot fastboot

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

   $ fastboot erase system
   $ fastboot flash system system.img

4. 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

5. Reinicia el dispositivo en el bootloader:

   $ fastboot reboot-bootloader

6. Inhabilita la verificación de inicio verificado mientras escribes en la memoria flash el vbmeta proporcionado:

   $ fastboot --disable-verification flash vbmeta vbmeta.img

7. Reboot:

   $ fastboot reboot

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

$ fastboot delete-logical-partition product_a

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 main 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

Cómo cambiar el modo de la barra de navegación con adb

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.