Por primera vez en 13 años: nuevas API sin código fuente
Android siempre se ha presentado como uno de los mayores proyectos de código abierto del mundo. Sin embargo, el lanzamiento de Android 17 QPR1 (Quarterly Platform Release 1) el 15 de septiembre de 2026 trajo consigo algo que no ocurría desde 2012: la introducción de nuevas API para desarrolladores sin publicar el código fuente correspondiente en AOSP (Android Open Source Project). Estas nuevas API solo se ejecutan actualmente en los terminales Pixel, dejando completamente al margen a fabricantes como Samsung, Xiaomi u OPPO.
La última vez que se vivió una situación similar fue con Android 3.x Honeycomb, aquella versión exclusiva para tabletas cuyo código nunca llegó a abrirse formalmente. Tras la etapa de Honeycomb, Google dedicó más de una década a demostrar al mundo que «Android es código abierto». Ahora, Android 17 coloca un asterisco explícito sobre esa histórica promesa.
GrapheneOS da la voz de alarma
El 16 de septiembre, GrapheneOS —un sistema operativo independiente centrado en la privacidad y la seguridad— denunció públicamente esta práctica a través de la red social Mastodon, logrando 51 réplicas y 92 favoritos en pocas horas. El equipo de GrapheneOS reveló un detalle aún más revelador: ya habían concluido la adaptación del código a Android 17 QPR1 antes de su lanzamiento oficial el 15 de septiembre, «pero no contaban con autorización para publicarlo».
Figura: Publicación oficial de GrapheneOS en Mastodon donde se denuncia que el código fuente de Android 17 QPR1 no fue liberado en AOSP. Fuente: Cuenta de Mastodon de GrapheneOS
Dicho de otro modo, el código estaba listo, pero el visto bueno de Google jamás llegó. GrapheneOS se ha visto obligado a trabajar a contracorriente, realizando una retroportabilidad (backport) del firmware, los controladores del kernel, los drivers de espacio de usuario y las capas de abstracción de hardware (HAL) de los Pixel desde Android 17 QPR1 hacia el Android 17 estándar. Para el resto de fabricantes de smartphones el panorama es todavía más desalentador: tendrán que esperar hasta diciembre de 2026, con el lanzamiento de QPR2, para recibir dichos parches. Google ha otorgado a su propia gama Pixel una ventana de exclusividad de tres meses completos.
Aunque la Licencia Pública General de GNU (GPL) obliga legalmente a Google a liberar las modificaciones del código fuente, no impone un calendario estricto sobre el ritmo de entrega. GrapheneOS solicitó el código correspondiente a la compilación CD1A.260905.001.A1 el 1 de septiembre, pero Google no facilitó el acceso hasta el 17 de septiembre, tras 16 días de espera. La licencia estipula que «debe entregarse», pero en ningún momento especifica que deba hacerse de forma inmediata.
Los parches de seguridad también quedan atrapados en la ventana de exclusividad
La exclusividad en funciones comerciales podría justificarse como una maniobra de mercado agresiva. Sin embargo, aplicar esa misma exclusividad a parches de seguridad resulta indefendible.
GrapheneOS advirtió de que el boletín de actualización de septiembre de 2026 para los Pixel incluye parches de seguridad adicionales destinados a componentes estándar de la plataforma Android presentes en terminales de terceros. Dichos componentes sufren exactamente las mismas vulnerabilidades en cualquier otro dispositivo. Pese a ello, estas correcciones críticas no se incorporaron al Boletín de Seguridad de Android general de septiembre de 2026 ni se distribuyeron a través de los paquetes de parches previos.
Figura: Página de cambios entre los niveles de API 37 y 37.1 en el portal oficial para desarrolladores de Android. Fuente: developer.android.com
Las declaraciones de GrapheneOS fueron demoledoras: «Google no debería bloquear el acceso a los parches de seguridad del código estándar de la plataforma Android a los demás fabricantes, pero eso es exactamente lo que ha empezado a hacer». Y añadieron con ironía: «Sería interesante saber si el equipo legal de Google es consciente de que están concediendo a los Pixel meses de acceso anticipado a nuevas funciones y correcciones de errores, incluyendo ciertos parches de seguridad esenciales».
En el plano empresarial, retrasar los parches supone dar a los Pixel tres meses de ventaja comercial. En el plano del usuario final, implica que miles de millones de dispositivos Android no pertenecientes a la familia Pixel quedan expuestos a fallos conocidos durante noventa días adicionales. Las nuevas funciones pueden esperar; las vulnerabilidades de seguridad, no.
La comunidad pide una bifurcación, pero ¿quién asume el coste de ingeniería?
El debate estalló en Hacker News, sumando 389 puntos y 177 comentarios. El comentario más valorado conectó las decisiones recientes de Google —retrasos en parches upstream, embargos sobre el código fuente y endurecimiento de la atestación de dispositivos— para extraer una conclusión contundente: «Google simplemente lamenta haber hecho que Android fuera de código abierto». Otra opinión fue aún más tajante: o la comunidad ejecuta un hard fork de inmediato, o pronto ni siquiera existirá la posibilidad de contar con una alternativa viable.
No obstante, las proclamas chocan frontalmente contra la realidad de la ingeniería de software. Mantener una bifurcación independiente de Android exige asumir una carga técnica idéntica a la que soporta Google: adaptación continua de controladores, parches mensuales de seguridad, pruebas exhaustivas con la suite de compatibilidad (CTS) y el mantenimiento de un ecosistema gigantesco, todo ello con una quema incesante de capital. Si el escritorio Linux no ha logrado sustituir a Windows tras dos décadas de desarrollo, bifurcar un sistema operativo móvil de la complejidad de Android entraña dificultades todavía mayores. La propia GrapheneOS admitió que los Pixel se han convertido ahora en dispositivos «notablemente más difíciles de soportar». La que fuera una de las mayores ventajas de los Pixel —su cercanía al AOSP puro para el desarrollo de ROMs comunitarias— se está esfumando a gran velocidad.
Las licencias de código abierto controlan el código, pero no los plazos
El modelo abierto de Android siempre descansó sobre una premisa histórica a menudo olvidada: Google apostó por el código abierto en 2008 porque necesitaba imperiosamente que los fabricantes le ayudaran a colonizar el mercado. Marcas como Samsung, Huawei y Xiaomi instalaron Android en más del 70% de los teléfonos inteligentes del planeta. Con el dominio absoluto asegurado, el concepto de «código abierto» pasó de ser una seña de identidad innegociable a convertirse en una moneda de cambio estratégica. Android 17 QPR1 representa una exhibición clara de ese poder: tanto las novedades funcionales como los parches de seguridad pertenecen a los Pixel durante tres meses antes de que nadie más pueda acceder a ellos.
Al ecosistema que se sitúa aguas abajo solo le quedan tres salidas: los fabricantes esperan pacientemente a la llegada de QPR2 en diciembre; proyectos como GrapheneOS recurren a una titánica labor de ingeniería inversa; o los usuarios terminan comprando un Pixel. Los tres caminos conducen al mismo destino: Google tiene el control absoluto del reloj. La licencia de código abierto garantiza que el código acabará siendo público tarde o temprano. Sin embargo, la ventana de tres meses introducida en ese «tarde o temprano» resulta más que suficiente para que el Pixel tome una ventaja insalvable en prestaciones, seguridad y posicionamiento en el mercado.
Enlaces de referencia:
- Publicación de GrapheneOS en Mastodon
- Debate en Hacker News
- Página de diferencias de API en el portal de desarrolladores de Android
- Boletín de seguridad de Android (septiembre de 2026)
