Google no va a acabar con AOSP, pero sí va a poner las cosas más difíciles a los desarrolladores de ROMs

Si eres de los que, como yo, han pasado horas cacharreando con tu móvil Android, flasheando ROMs personalizadas, probando las últimas versiones de Android antes que nadie o simplemente exprimiendo al máximo tu dispositivo, seguramente conozcas bien el término AOSP. Para los que no, es el acrónimo de Android Open Source Project, la base de código abierto de Android, el "esqueleto" sobre el que se construye todo el sistema operativo. Es la puerta de entrada para la comunidad de desarrolladores de ROMs personalizadas, aquellos que crean versiones de Android más limpias, más rápidas o con funciones únicas para nuestros teléfonos.

Pero, a veces, la relación de Google con esa comunidad es un tira y afloja constante. Hace unos meses, ya hubo algo de revuelo cuando Google anunció que desarrollaría Android OS de forma más privada, para simplificar su proceso interno. Aquella vez, la polémica se calmó rápido porque el impacto fue mínimo, y Google prometió que las liberaciones del código fuente seguirían su curso. Sin embargo, ahora, una reciente omisión en la última versión de AOSP para Android 16 ha encendido de nuevo las alarmas, generando un golpe importante para quienes se dedican a las Custom ROMs en los Pixel. Aunque Google niega que AOSP vaya a desaparecer, la realidad es que les ha puesto las cosas mucho más difíciles.

El Pixel ya no es la referencia: qué ha cambiado y por qué

Como prometieron, Google publicó el código fuente de Android 16 esta semana, poco después del lanzamiento de la nueva versión, lo que permite a los desarrolladores independientes compilar sus propias versiones del nuevo sistema operativo. Este código se subió a AOSP, como siempre, bajo la licencia Apache 2.0. Hasta aquí, todo normal.

Pero la cosa cambió. Varios desarrolladores notaron rápidamente una omisión flagrante en la liberación del código fuente de Android 16: faltaban los "device trees" para los dispositivos Pixel. Además, Google tampoco subió los nuevos "driver binaries" (archivos que permiten al software comunicarse con el hardware) para cada Pixel, y el código fuente del kernel (el "corazón" del sistema) se lanzó con un historial de "commits" (cambios realizados) "squashed", es decir, comprimido en uno solo. Esto fue preocupante, ya que Google llevaba años compartiendo toda esta información.

Estas omisiones llevaron a algunos a especular que Google estaba dando el primer paso para cargarse AOSP. Sin embargo, Seang Chau, Vicepresidente de Plataforma Android de Google, desmintió estas afirmaciones categóricamente en una publicación en X, asegurando que "AOSP no va a desaparecer".

We're seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures.

AOSP needs a reference target that is…

— Seang Chau (@seangchau) June 12, 2025

Según Google, la omisión de los "device trees" de Pixel es intencionada. Explican que AOSP necesita una "referencia" que sea "flexible, configurable y asequible", e "independiente de cualquier hardware particular, incluidos los de Google". En lugar de usar los Pixel como base para las compilaciones de AOSP, Google ahora utilizará el dispositivo virtual de Android llamado "Cuttlefish" como su objetivo de referencia.

Este Cuttlefish se ejecuta en PC y permite a los desarrolladores probar nuevas funciones de hardware. Google también seguirá dando soporte a las GSI (Imágenes de Sistema Genéricas), que pueden instalarse en casi cualquier dispositivo Android.

La lógica de Google es, en parte, sólida: AOSP se construyó para ser una plataforma abierta para diversos fabricantes y arquitecturas. Y Cuttlefish, al ser un dispositivo virtual, es una referencia más "neutral" que un Pixel, que al final es un hardware de consumo muy personalizado. Sin embargo, al ser virtual, Cuttlefish tiene sus limitaciones a la hora de simular el comportamiento real del hardware.

La odisea de construir una ROM personalizada para los Pixel

LineageOS es una de las plataformas de ROMs históricas del universo Android

Aquí es donde viene el verdadero "dolor de cabeza" para la comunidad de desarrolladores de ROMs personalizadas. Nolen Johnson, un veterano de LineageOS (uno de los proyectos de Custom ROM más importantes), ha dicho que el proceso de construir estas ROMs para los teléfonos Pixel va a ser "doloroso" a partir de ahora.

Antes, Google lo ponía fácil. Los desarrolladores solo tenían que "tirar de las configuraciones que Google creaba", añadir sus propias personalizaciones y compilar. Era relativamente sencillo. Pero ahora, esa ayuda se ha esfumado. Los desarrolladores tendrán que coger los antiguos "device trees" que Google lanzó para Android 15 y, básicamente, "adivinar a ciegas y hacer ingeniería inversa a partir de los binarios preconstruidos qué cambios son necesarios cada mes".

¿Por qué es tan grave esto? Porque para crear una compilación completa de Android para un dispositivo (no solo una GSI), se necesita un "device tree". Este es una colección de archivos de configuración que definen el diseño del hardware, los periféricos, las listas de archivos propietarios y otros detalles específicos del dispositivo, permitiendo que el sistema de compilación cree una imagen adecuada para él. Antes, Google se encargaba de este trabajo. Ahora, los desarrolladores deberán crear sus propios "device trees" sin tener acceso al código fuente propietario necesario.

Para colmo, la decisión de Google de comprimir el historial de cambios del código fuente del kernel también pone trabas. El código fuente del kernel del Pixel a menudo se utilizaba como "punto de referencia para que otros dispositivos tomaran características, correcciones de errores y parches de seguridad", pero al reducir el historial a un solo "commit", esto ya no es viable.

Es cierto que Google no tiene la obligación legal de liberar estos "device trees", de proporcionar los "driver binaries" ni de compartir el historial completo del kernel (de hecho, es uno de los pocos fabricantes que lo ha hecho durante años). La razón por la que lo hacía era porque el Pixel se consideraba una plataforma de referencia para AOSP, y quería facilitar las compilaciones. Pero al decidir dejar de usar el Pixel como dispositivo de referencia para AOSP, Google ha "quitado la alfombra" a desarrolladores de proyectos tan importantes como LineageOS o GrapheneOS, que construyen Android para los Pixel. Seguirán pudiendo hacerlo, pero el camino será mucho más difícil y costoso.

El futuro de las Custom ROMs en Pixel: ¿más difícil, pero no imposible?

El software del Google Pixel 9a, basado en Android 15 / Fotografía de Christian Collado

Esta nueva decisión de Google es un golpe importante para la comunidad de desarrolladores de Custom ROMs, especialmente aquellos que trabajan con los Pixel. Reaviva los temores que ya surgieron con la noticia de que Android se desarrollaría de forma más privada. Parece que Google busca un equilibrio cada vez más complejo entre su compromiso con el código abierto y la necesidad de optimizar sus propios procesos y, quizás, mantener un mayor control sobre la experiencia de sus dispositivos estrella.

Sin embargo, la comunidad de modding de Android es increíblemente resiliente. Es muy probable que, aunque el proceso sea ahora más tedioso y requiera más ingeniería inversa, los desarrolladores encuentren la manera de seguir llevando las Custom ROMs a los Pixel. Lo que sí es seguro es que este cambio añade una capa de dificultad y tiempo que antes no existía. Es un movimiento que, aunque no mata a AOSP, sí complica la vida a quienes, desde su pasión y conocimiento, construyen un Android diferente para el resto de usuarios. Veremos cómo evoluciona este nuevo capítulo en la relación entre Google y su comunidad más "underground".