GrapheneOS acusa a Google de retrasar APIs y parches de Android fuera de AOSP
El proyecto denuncia que Android 17 QPR1 introduce APIs nuevas sin publicarlas por AOSP y que parte de los parches de seguridad llegan antes a los Pixel que al resto
Android 17 QPR1 ya está en los Pixel, pero parte de lo que trae no ha salido por donde debería. GrapheneOS publicó el 17 de septiembre una serie de mensajes en Mastodon en los que acusa a Google de repartir nuevas APIs de desarrollo y parches de seguridad solo a través de las actualizaciones de Pixel, sin publicarlos a la vez en AOSP ni en el boletín de seguridad de Android.
El marco es el Pixel Drop de septiembre, en el que Google liberó QPR1 para la serie Pixel 11 con la expansión de los efectos de transparencia y desenfoque de Material 3 Expressive, cambios en multitarea y controles multimedia.
El primer caso desde Honeycomb
El punto que más pesa es el de las APIs. Según GrapheneOS, QPR1 es la primera versión de Android desde Honeycomb (3.x) que añade APIs nuevas para desarrolladores sin dejarlas disponibles por AOSP. Habrá que esperar a QPR2, prevista para diciembre, para verlas en el árbol público. Traducido a la práctica: durante unos meses, quien no tenga un Pixel programa contra una plataforma que no es la que Google usa internamente, y los fabricantes que construyen sobre AOSP no pueden tocar esas interfaces.
Con los parches pasa algo parecido. El proyecto sostiene que Google mete en la actualización de Pixel correcciones que afectan a la plataforma Android en general, pero no las publica simultáneamente en el Android Security Bulletin ni en los canales de vista previa de seguridad. El resto de fabricantes podría no recibirlas hasta QPR2, en diciembre. Es decir, meses de ventana en los que un Pixel está corregido y un dispositivo de otra marca, con el mismo código de base, no.
Para GrapheneOS, el resultado es una ventaja competitiva artificial para la gama Pixel: acceso anticipado a funciones, a arreglos de vulnerabilidades y a parches de seguridad importantes. La ROM califica la situación de potencialmente anticompetitiva y, como mínimo, alejada de la tradición de ecosistema abierto que Android venía manteniendo.
Hay un tercer frente, el del código fuente. GrapheneOS asegura que el 1 de septiembre pidió el código de una compilación concreta de Pixel y no obtuvo acceso hasta varias semanas después, algo que considera un incumplimiento de las obligaciones que impone la GPL.
El problema para el proyecto no es solo teórico. Si QPR1 y QPR3 dejan de sincronizarse con AOSP como antes, GrapheneOS puede tener la adaptación terminada y aun así no poder publicarla: le faltarían el permiso de distribución, el firmware, los drivers o el código HAL. Sin esas piezas, la actualización se queda en el cajón por mucho que el trabajo esté hecho.
A quién afecta esto: a cualquiera que mantenga una ROM basada en AOSP, a fabricantes que dependen de los plazos públicos de Google y, de rebote, a quien tenga que decidir si un parque de dispositivos no-Pixel sigue recibiendo correcciones a tiempo. Queda por ver si Google responde a la acusación y si QPR2 devuelve de verdad esas APIs y esos parches al canal público, o si el desfase se convierte en la nueva normalidad del ciclo de Android.
