Si llevas un tiempo trasteando con Android, seguro que has oído hablar de Project Treble y las imágenes GSI, sobre todo cuando se habla de actualizaciones, ROMs personalizadas o de exprimir al máximo la vida útil de un móvil. Lo que quizá no está tan claro es qué son exactamente, por qué existen, qué limitaciones tienen y hasta dónde se puede llegar hoy en día con ellas sin convertir tu teléfono en un bonito pisapapeles.
En las siguientes líneas vamos a profundizar en qué es Project Treble, cómo cambió la arquitectura de Android, qué son las GSI (Generic System Image), para qué las usa Google, cómo las aprovecha la comunidad para instalar versiones “puras” de Android o ROMs personalizadas, qué requisitos debe cumplir tu dispositivo y cuáles son los pasos y precauciones más importantes a la hora de flashearlas. La idea es que, cuando termines de leer, tengas claro qué puedes hacer, qué no, y si te compensa meterte en este fregado.
¿Qué es Project Treble y por qué cambió Android?
Antes de hablar de GSI, hay que entender qué resolvió Project Treble en la arquitectura de Android. Hasta Android 7.x, gran parte del código específico de cada fabricante y del proveedor de hardware (Qualcomm, MediaTek, etc.) estaba mezclado con el propio sistema. Eso hacía que, cada vez que Google publicaba una nueva versión, los fabricantes tuvieran que rehacer buena parte de su trabajo para adaptar controladores, capas y personalizaciones.
Con Treble, introducido inicialmente junto con Android 8.0 Oreo, Google reestructuró el sistema para separar con claridad dos bloques: por un lado, el marco del sistema operativo Android (framework, servicios del sistema, apps base); por otro, la capa específica del proveedor, que incluye las HAL (Hardware Abstraction Layers), controladores de hardware y demás componentes dependientes del SoC y del fabricante.
Para que estos dos mundos se entiendan sin pegarse tiros, Google definió una interfaz bien documentada llamada VINTF (Vendor Interface), que determina cómo se comunican el sistema y el proveedor, habitualmente mediante HAL escritas con HIDL (hasta Android 9) o AIDL (a partir de Android 10). Este contrato establece qué puede esperar el sistema de la capa del proveedor y viceversa.
En la práctica, esto significa que la imagen del sistema se hace más genérica y se reduce al Android “puro”, mientras que el código de proveedor se aloja en la partición vendor. Si la interfaz está bien definida y se cumple, una nueva versión de Android puede arrancar sobre una implementación de proveedor más antigua sin necesidad de actualizarla a la vez.
Analogía sencilla para entender Treble
Un modo muy gráfico de entender Project Treble es pensar en un coche, su conductor y la autoescuela. Imagina que el coche es el dispositivo, el conductor es el sistema operativo Android y los mandos del coche (volante, frenos, pedales) son las HAL y el resto del software del proveedor.
El conductor no necesita saber cómo está construido el sistema de frenos; solo necesita que el pedal de freno responda de una forma estándar. Esa forma estándar de usar los mandos sería la interfaz del proveedor (VINTF), que el sistema aprende “en la autoescuela”. Mientras todos los coches (implementaciones de proveedor) usen el mismo tipo de volante y frenos estandarizados, cualquier conductor (versión de Android) que haya pasado por esa autoescuela podrá conducirlos sin problema.
Gracias a esta separación y a esa “autoescuela” común, Treble consigue que Android sea más modular y que actualizar solo el sistema sin tocar la capa del proveedor sea técnicamente posible en muchos casos. Y ahí es donde entran en juego las GSI.
Qué es una GSI (Generic System Image)
Una GSI es, en esencia, una imagen genérica del sistema basada en AOSP (Android Open Source Project) sin modificaciones del fabricante ni añadidos extra. Es la implementación “Android puro” más limpia que vas a encontrar, compilada por Google (o por la comunidad) para que funcione en dispositivos diferentes que cumplan con Treble.
La idea es que esta imagen de sistema no está pensada para un hardware concreto, sino para cualquier dispositivo Android moderno que respete el contrato de interfaz entre sistema y proveedor. Por eso se la llama genérica: en lugar de adaptarse a un móvil en particular, se apoya completamente en la capa vendor del dispositivo para interactuar con el hardware.
Google mantiene las GSI como parte de su estrategia de pruebas de compatibilidad y verificación de Treble. De hecho, los fabricantes tienen la obligación de arrancar correctamente ciertas GSI en sus dispositivos para pasar pruebas oficiales como VTS (Vendor Test Suite) y CTS-on-GSI (un subset del Compatibility Test Suite ejecutado sobre la GSI).
Para qué se usan las GSI y quién las aprovecha
Dentro del ecosistema Android, las GSI tienen tres grandes usos principales. El primero, y más importante para Google y los fabricantes, es servir como base para las pruebas oficiales de compatibilidad. Los OEM sustituyen la imagen del sistema de su firmware por una GSI y ejecutan VTS y CTS-on-GSI para comprobar que su implementación de proveedor respeta la interfaz definida.
En segundo lugar, las GSI son una herramienta muy valiosa para desarrolladores de aplicaciones y de sistema. Un desarrollador puede instalar una GSI basada en una versión futura de Android (por ejemplo, una Developer Preview o una beta) en un dispositivo real compatible con Treble y probar su app con el Android más nuevo, sin depender de emuladores ni de que su modelo reciba una beta oficial.
Por último, están las GSI que usa la comunidad de ROM personalizadas. Aunque Google concibió las GSI solo como una herramienta de desarrollo y certificación, muchos desarrolladores vieron el potencial de tener una imagen de Android puro que, en teoría, puede arrancar en cualquier dispositivo totalmente Treble. De ahí han surgido proyectos comunitarios que distribuyen GSIs “afinadas” y ROM completas empaquetadas como GSI para todo tipo de dispositivos.
Limitaciones reales de las GSI en uso diario
Sobre el papel, una GSI debería arrancar en cualquier dispositivo que cumpla con Project Treble. En la práctica, las cosas son bastante más complicadas. Cuando se lanzaron los primeros móviles con Android 8.0 Oreo, muchos de ellos no estaban completamente “treblizados”: aunque en teoría soportaban Treble, su compatibilidad con GSI era parcial o directamente inexistente.
No fue hasta Android 9 Pie cuando empezaron a aparecer los primeros dispositivos realmente compatibles con Treble a nivel estricto. Sin embargo, incluso hoy muchas GSI oficiales de Google funcionan solo a medias en ciertos modelos: puede faltar audio en llamadas, fallar el audio Bluetooth, no reconocer correctamente sensores específicos o directamente no arrancar en dispositivos con hardware poco común.
Además, AOSP durante años no incluyó HAL genéricas para determinados componentes cada vez más habituales, como los lectores de huellas bajo la pantalla o ciertos módulos de radio de banda ultraancha (UWB). Google ha ido añadiendo soporte genérico según introducía ese hardware en sus propios Pixel, pero sigue habiendo brechas.
Por todo esto, una GSI compilada tal cual desde AOSP no suele ser apta para uso diario en un móvil principal. Google lo deja bastante claro: están pensadas para validar el cumplimiento de Treble y para pruebas de apps, no para que el usuario medio las instale en su teléfono personal. Para convertirlas en algo razonablemente usable, hace falta mucho trabajo extra por parte de la comunidad.
El papel de la comunidad: GSIs mejoradas y ROMs genéricas
Dentro de la escena de ROMs personalizadas, uno de los nombres clave es phhusson, un desarrollador que se propuso comprobar de forma realista esa promesa de “una imagen genérica que arranca en cualquier dispositivo Treble”. Tras muchas horas de pruebas y depuración, consiguió la primera GSI comunitaria que arrancaba en teléfonos de varios fabricantes con SoC distintos.
Su trabajo ha evolucionado hasta convertirse en una GSI de referencia dentro de la comunidad, que corrige fallos presentes en las compilaciones de Google, añade compatibilidad con hardware problemático y ofrece multitud de ajustes específicos para modelos concretos. Por ejemplo, sus builds resuelven los problemas clásicos de audio en llamada y Bluetooth A2DP que todavía afectan a algunas GSI oficiales.
Además de los parches para errores generales, estas GSIs comunitarias incluyen superposiciones y configuraciones que ajustan cosas como el brillo automático, la tasa de refresco en pantallas de alta frecuencia o la detección de sensores. A menudo incorporan también una app de ajustes específicos desde la que activar o desactivar soluciones para determinados dispositivos.
Muchas ROM populares, como LineageOS o proyectos derivados, aprovechan la base de estas GSIs y los scripts de compilación para ofrecer sus propias imágenes genéricas. En vez de mantener ports individuales para cientos de modelos, se apoyan en Treble para publicar una sola GSI que puede funcionar en cualquier dispositivo compatible con ligeros ajustes.
Requisitos para poder instalar una GSI
Aunque Project Treble y las GSI abren muchas puertas, no basta con tener un Android relativamente moderno. Para que puedas flashear una GSI con ciertas garantías, tu dispositivo debe cumplir varios requisitos técnicos concretos.
En primer lugar, es imprescindible que el móvil o la tablet se haya lanzado al mercado ya con soporte Treble, normalmente con Android 9 Pie o superior de fábrica. Muchos modelos que actualizaron a Android 9 desde una versión anterior no alcanzan la compatibilidad completa, incluso si el sistema reporta que Treble está habilitado.
El primer chequeo básico lo puedes hacer por ADB con el comando:
adb shell getprop ro.treble.enabled
Si el valor devuelto es false, olvídate: ese dispositivo no es compatible con GSI. Si devuelve true, entonces soporta Treble, pero aún falta validar el nivel de compatibilidad.
El segundo paso es comprobar si tu móvil es compatible con varias versiones de Android vía GSI o solo con la misma versión. Para eso se consulta un archivo de configuración de la implementación del proveedor. Según la versión, se utiliza:
- /system/etc/ld.config.version_API.txt (en algunas versiones anteriores, con “API” sustituido por el número de API) o
- /system/etc/ld.config.version_identifier.txt (en ramas más recientes de Android).
El comando típico suele ser algo como:
adb shell cat /system/etc/ld.config.version_identifier.txt | grep -A 20 «[vendor]»
En la salida, dentro del bloque [vendor], tienes que fijarte en el valor de namespace.default.isolated:
- Si es true, el dispositivo es completamente compatible con el VNDK y puede arrancar GSI basadas en versiones de Android posteriores a la que lleva instalada (siempre que la arquitectura coincida).
- Si es false, el dispositivo no cumple todas las condiciones del VNDK y solo puede cargar una GSI de la misma versión de Android que el sistema actual. Por ejemplo, un teléfono con Android 10 solo podrá arrancar GSIs de Android 10.
Otro requisito clave es que el bootloader esté desbloqueado. Sin bootloader desbloqueado no hay forma de escribir la imagen del sistema desde fastboot. Suelen existir opciones en el menú de desarrollador como “Desbloqueo OEM” que te permiten habilitar este proceso y luego ejecutar el comando correspondiente (por ejemplo, fastboot oem unlock o fastboot flashing unlock, según el fabricante).
También es imprescindible que la arquitectura de CPU de la GSI coincida con la del dispositivo. Para saber qué GSI bajar, puedes ejecutar:
adb shell getprop ro.product.cpu.abi
En un Pixel 5, por ejemplo, este comando devuelve arm64-v8a, por lo que te tocaría usar una GSI arm64. Si tu dispositivo es x86 o x86_64 (más habitual en emuladores y algunos dispositivos muy concretos), deberás descargar la variante correspondiente.
Por último, conviene recordar el impacto que tiene este proceso a nivel de seguridad: al desbloquear el bootloader se rompe SafetyNet y puede perderse Widevine L1. Eso implica que muchas apps bancarias o de pagos pueden dejar de funcionar, y que servicios de streaming quizá ya no reproduzcan contenido en alta resolución. Además, salvo casos muy puntuales (como ROMs centradas en seguridad tipo GrapheneOS, CalyxOS o DivestOS), instalar una GSI genérica implica renunciar a parte del modelo de seguridad estándar de Android.
Comprobaciones adicionales y relación con Keymaster
A partir de Android 9, Google ajustó también el comportamiento de Keymaster (el componente de seguridad que gestiona claves criptográficas en hardware) para no bloquear el inicio de GSIs válidas. En versiones previas, los dispositivos con Keymaster 3 o anteriores debían contrastar que la versión de Android y el parche de seguridad reportados por el sistema coincidieran con los que el bootloader pasaba al arranque.
Si se intenta arrancar una GSI con una versión distinta, esa verificación podía fallar y impedir que el sistema terminara de iniciar. Por ello, en Android 9 y posteriores se especifica que Keymaster debe omitir esa comprobación cuando se trata de una GSI, o bien que los proveedores actualicen a Keymaster 4 y su implementación correspondiente.
Este cambio forma parte del esfuerzo global de Google por hacer viable el arranque de GSIs en dispositivos Treble reales sin reventar los mecanismos de seguridad más sensibles, manteniendo el equilibrio entre flexibilidad y protección.
Dónde descargar GSIs oficiales y comunitarias
Dependiendo de para qué quieras usar una GSI, tienes varias fuentes posibles. Si eres desarrollador de apps o simplemente quieres probar la versión más reciente de Android “puro”, Google publica imágenes GSI en:
- La página oficial de versiones de GSI, donde encontrarás GSIs de versiones preliminares (Developer Preview, betas) y GSIs de Android con servicios de Google (GMS).
- El sitio de integración continua de AOSP (ci.android.com), donde se suben compilaciones preconstruidas sin GMS, útiles para pruebas más cercanas a AOSP puro.
Por otro lado, si lo tuyo es el mundo de las ROM personalizadas, existen listas comunitarias de GSIs (mantenidas en foros como XDA o wikis específicas) donde se recopilan proyectos basados en phhusson y otros desarrolladores. En estas listas suele indicarse en qué dispositivos han sido probadas, qué bugs conocidos tienen y qué variantes hay (con o sin GApps, con root, con distintas capas visuales, etc.).
Importante: Google deja claro que los fabricantes no deben usar las GSIs públicas destinadas a desarrolladores o comunidad para pruebas de conformidad oficiales. Para eso tienen canales y builds específicas validadas para el programa de certificación.
Cómo compilar tu propia GSI desde AOSP
Si tienes algo más de nivel técnico, también es posible compilar una GSI directamente del código fuente de Android. Desde Android 9 en adelante, AOSP mantiene ramas dedicadas para GSI con el nombre DESSERT-gsi (por ejemplo, android12-gsi). Estas ramas incluyen Android tal y como se lanza, junto con parches específicos para GSIs y actualizaciones de seguridad.
El flujo general consiste en inicializar el repositorio apuntando a la rama adecuada, sincronizar el código, cargar el entorno de compilación y seleccionar el objetivo GSI que corresponda. Por ejemplo, para compilar un gsi_arm64-userdebug basado en android12-gsi se usaría algo aproximado a:
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
Al terminar, se genera una system.img genérica en la carpeta de salida correspondiente (por ejemplo, out/target/product/generic_arm64). Esa imagen puede flashearse después en dispositivos compatibles, siguiendo el proceso estándar de instalación de GSI.
A nivel de variantes, las GSIs se construyen para distintas arquitecturas y configuraciones de Binder. Las más comunes para dispositivos de consumo son:
- gsi_arm (ARM 32 bits, Binder 64 bits, system-as-root)
- gsi_arm64 (ARM64, Binder 64 bits, system-as-root)
- gsi_x86 (x86 32 bits, Binder 64 bits, system-as-root)
- gsi_x86_64 (x86_64, Binder 64 bits, system-as-root)
Cada una se publica en sabores user y userdebug, dependiendo de si la build está orientada a entornos de usuario finales o a pruebas y depuración más intensivas.
Evolución de las GSI a través de las versiones de Android
Con cada gran versión de Android, Google ha ido ajustando el funcionamiento de las GSIs, cambiando nombres de objetivos de compilación, añadiendo particiones y puliendo la integración con nuevas funciones del sistema.
En Android 9 se introdujo por completo el esquema system-as-root, donde la raíz del sistema se monta directamente como raíz del dispositivo, incluso para terminales sin particiones A/B. Las GSI para este entorno fusionaron además gran parte del trabajo del emulador, de modo que productos como aosp_arm64 o aosp_x86 sirvieron de base para generar imágenes genéricas.
También a partir de Android 9 el uso de VNDK (Vendor Native Development Kit) se volvió obligatorio. VNDK asegura que los binarios nativos del sistema se relacionen con la capa vendor de forma compatible, lo que es clave para que la misma GSI funcione sobre distintas implementaciones de proveedor.
En Android 10, las GSIs pasaron a distribuirse oficialmente como builds de tipo user para las pruebas CTS-on-GSI, se simplificó el formato de las imágenes (formato sin dispersión, convertible con herramientas como img2simg) y se retiraron algunos objetivos heredados aosp_$arch_a, favoreciendo configuraciones modernas.
Android 11 introdujo la partición system_ext, pensada para alojar extensiones del sistema. Las GSIs tuvieron que adaptarse y colocar ese contenido bajo system/system_ext dentro de la propia system.img, manteniendo la compatibilidad con la estructuración nueva.
En Android 12, Google renombró los objetivos de compilación para pruebas oficiales a gsi_$arch, manteniendo al mismo tiempo las variantes aosp_$arch para desarrolladores de apps. También empezó a retirar más soluciones heredadas para dispositivos que seguían atascados en una adopción parcial de Treble desde Android 8.x. Además, se añadió una política SELinux específica userdebug dentro de la GSI para facilitar la depuración VTS con imágenes vendor_boot de depuración.
Por último, con Android 13, 14 y 15, los dispositivos que se lanzan con esas versiones deben usar GSIs firmadas gsi_$arch-user específicas de cada API para sus pruebas de cumplimiento, manteniéndose la base común en Android 12 pero con los parches correspondientes a cada ciclo.
Cómo instalar una GSI en un dispositivo compatible
Instalar una GSI sigue siendo, a día de hoy, un proceso delicado y no apto para principiantes absolutos. No hay un único conjunto de comandos que sirva para todos los dispositivos, porque cada fabricante organiza sus particiones y su fastboot a su manera. Aun así, el flujo general es bastante parecido.
Antes de nada, es fundamental hacer una copia de seguridad completa de tus datos y tener a mano el firmware original del dispositivo, ya sea en forma de imagen de fábrica o de paquete de recuperación oficial. En caso de que algo salga mal (bootloop, brick, etc.), necesitarás flashear de nuevo el sistema original para recuperar el teléfono.
Los pasos genéricos suelen ser estos:
- Desbloquear el bootloader. Cada marca tiene su procedimiento: en algunos casos se activa el “Desbloqueo OEM” en las opciones de desarrollador y luego se usa fastboot (por ejemplo, fastboot oem unlock o fastboot flashing unlock). Este paso borra todos los datos del usuario.
- Reiniciar en modo fastboot o fastbootd. Algunos dispositivos usan fastboot clásico, otros añaden fastbootd (fastboot reboot fastboot) para gestionar particiones dinámicas desde el propio sistema.
- Borrar la partición system actual. Comandos tipo fastboot erase system o, en esquemas A/B, fastboot erase system_a (y/o system_b), según las indicaciones del fabricante o de la guía específica de tu modelo.
- Deshabilitar temporalmente el arranque verificado (AVB) flasheando una imagen vbmeta adecuada: fastboot –disable-verification flash vbmeta vbmeta.img. Esta imagen vbmeta suele venir incluida en los paquetes GSI oficiales o puede ser una vbmeta “vacía” generada para tal fin.
- Flashear la GSI en la partición de sistema. Por ejemplo: fastboot flash system system.img o fastboot -w flash system nombre_de_la_imagen.img. La opción -w borra también datos de usuario para evitar conflictos.
- En dispositivos con particiones dinámicas o espacio limitado, puede ser necesario borrar la partición product (u otras lógicas) para dejar más espacio a system. Un ejemplo típico: fastboot delete-logical-partition product_a, haciendo coincidir el sufijo _a con el de system_a.
- Borrar datos de usuario y otras particiones relevantes (fastboot -w, wipe en recovery, etc.) para arrancar con un entorno limpio.
- Reiniciar el dispositivo y cruzar los dedos. El primer arranque suele tardar bastante más que los siguientes, así que paciencia.
En el caso concreto de los Pixel (Pixel 3 en adelante), Google documenta un flujo basado en fastbootd para flashear GSIs, que luego se ha demostrado bastante aplicable a otros dispositivos con un diseño de particiones similar, como algunas tablets y móviles recientes con particiones dinámicas.
Al arrancar una GSI, puede que encuentres detalles de comportamiento distintos a los de la ROM del fabricante: cambios en la interfaz de usuario, ausencia de funciones específicas (por ejemplo, gestos propietarios, modos de cámara avanzados, personalizaciones de audio, etc.) o incluso incompatibilidades con hardware que dependía de HAL no estándar.
Pequeños ajustes y personalizaciones tras instalar una GSI
Una vez tengas la GSI corriendo, es probable que quieras ajustar ciertos detalles de la experiencia de usuario que vienen configurados de forma genérica. Por ejemplo, el modo de navegación por gestos o los botones virtuales puede venir definido por superposiciones del proveedor que no encajen con lo que esperas.
Android permite cambiar el modo de la barra de navegación mediante overlays usando ADB. Un comando típico sería algo así:
adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode
Donde el modo puede ser threebutton, twobutton, gestural, etc., dependiendo de lo que admita la versión concreta de la GSI que estés utilizando. Esto resulta útil si, por ejemplo, la GSI arranca con navegación por tres botones y tú prefieres gestos completos.
En GSIs comunitarias avanzadas, como las basadas en el trabajo de phhusson, encontrarás además aplicaciones de ajustes específicos con opciones para solucionar problemas de brillo, audio, cámara, escalado de la interfaz y un largo etcétera, adaptadas a distintos fabricantes y modelos.
Más allá de la parte técnica, todo este ecosistema de GSI abre la puerta a alargar la vida útil de muchos dispositivos que ya no reciben soporte oficial, experimentar con versiones nuevas de Android y reducir, aunque sea un poco, la cantidad de hardware que acaba en un cajón o directamente en la basura.
Project Treble y las imágenes GSI han convertido un sistema históricamente monolítico y difícil de actualizar en algo mucho más modular, verificable y flexible. Aunque instalar una GSI siga siendo un proceso con riesgos, limitaciones y un cierto nivel de frikismo necesario, el avance es evidente: desde permitir a Google y a los fabricantes probar mejor sus dispositivos hasta ofrecer a los usuarios avanzados y a la comunidad de ROMs una base común sobre la que construir experiencias alternativas de Android en una enorme variedad de dispositivos.