Hace pocos días se dio a conocer la noticia sobre un nuevo cambio que ha implementado Google en el desarrollo de Android, y es que ahora el nuevo modelo de desarrollo para Android a eliminando la publicación de avances intermedios en el dominio público y restringiendo la revisión abierta de los cambios en sus componentes. Aunque Android seguirá siendo una plataforma de código abierto, licenciada bajo Apache 2.0, el código solo se liberará en el repositorio de AOSP (Android Open Source Project) una vez que cada nueva versión esté completamente lista.

Hasta ahora, el desarrollo de Android ha seguido un modelo mixto, donde algunas partes, como la pila Bluetooth, se desarrollaban públicamente, mientras que otras se mantenían en repositorios internos de Google hasta el lanzamiento. Además, los fabricantes de dispositivos con licencia GMS (Google Mobile Services) tenían acceso a la rama interna antes de la publicación oficial del código fuente.

Sin embargo, Google ha decidido abandonar esta estrategia y migrar todo el desarrollo a su propia rama interna, eliminando la división entre código público y privado. En adelante, todas las contribuciones y mejoras se realizarán de forma cerrada, y solo se liberará el código cuando la versión final esté lista para su distribución.

Se menciona que este cambio no afectará la disponibilidad del código para los desarrolladores de firmware basado en AOSP, ya que estos suelen trabajar sobre versiones ya etiquetadas y no en la rama principal en desarrollo. No obstante, sí supondrá desafíos para aquellos interesados en monitorear los cambios en tiempo real, ya que ya no podrán seguir la evolución de componentes individuales, sino que tendrán que analizar los cambios una vez que la versión completa se haga pública.

¿Por qué hay partes de Android que se desarrollan en privado?
Por lo general, lleva más de un año lanzar un dispositivo al mercado. Y, por supuesto, los fabricantes de dispositivos quieren entregar el software lo más actualizado posible. A la vez, los desarrolladores no quieren realizar el seguimiento constante de nuevas versiones de la plataforma cuando escriben el código de las apps. Se genera tensión en ambos grupos entre el envío de productos y el no querer quedar rezagado.

Para solucionar este problema, algunas partes de la próxima versión de Android, incluidas las APIs de la plataforma principal, se desarrollan en una rama privada. Estas APIs constituyen la próxima versión de Android. Nuestro objetivo es centrar la atención en la versión estable actual del código fuente de Android mientras creamos la próxima versión de la plataforma.

Algunos desarrolladores mencionan que esté nuevo modelo también dificultará las contribuciones externas al proyecto, pues la base de código de AOSP estará siempre desactualizada respecto a la rama interna, limitando la capacidad de la comunidad para participar activamente en la evolución de Android.

Entre los elementos que dejarán de desarrollarse abiertamente y se trasladarán por completo a la rama interna se incluyen:

• El sistema de compilación de Android
• El motor de actualizaciones
• La pila Bluetooth
• El marco de virtualización
• La configuración de SELinux

Motivos de la decisión de Google

La razón principal de este cambio, según Google, es simplificar el proceso de desarrollo. Mantener dos ramas paralelas generaba una acumulación de diferencias entre ellas, lo que requería un esfuerzo adicional para sincronizar cambios y fusionar parches entre la versión pública y la interna. Esta brecha se hace evidente al comparar una compilación limpia de AOSP con las versiones beta más recientes de Android 16, las cuales se basan en la rama interna de Google.

Si bien la transición a un modelo de desarrollo basado en trunk ha ayudado a reducir la discrepancia, esta aún persiste y sigue representando un desafío para Google.

Además, como la mayoría del desarrollo de la API ya se realizaba en la rama interna, la pública quedaba frecuentemente desactualizada, provocando conflictos al trasladar cambios entre ambas. Con el nuevo modelo, Google busca optimizar la gestión del código y reducir la complejidad de integración, aunque esto signifique una menor transparencia para la comunidad.