GrapheneOS denuncia que las APIs de Android 17 QPR1 siguen siendo exclusivas del Pixel
El proyecto asegura que las nuevas APIs para desarrolladores no llegan al AOSP y que los parches de septiembre de 2026 se retienen al resto de fabricantes hasta diciembre.
GrapheneOS afirma que Android 17 QPR1 incorpora APIs nuevas para desarrolladores de aplicaciones que no han salido al Android Open Source Project: se quedan dentro del software de Pixel. El proyecto sostiene además que los parches de septiembre de 2026 para componentes estándar de la plataforma Android no están llegando al resto de fabricantes de equipos, y que no lo harán hasta Android 17 QPR2, cuya publicación sitúa en diciembre de 2026.
Son afirmaciones del propio proyecto, sin documentación de Google que las acompañe. La compañía no ha dicho nada al respecto.
Port hecho, pero sin salida
El equipo dice que ya tiene terminado el port a QPR1 y que no puede distribuirlo. En lugar de eso está haciendo backport de firmware, drivers y HALs de Pixel a Android 17, esto es, arrastrar piezas del dispositivo que normalmente vienen con la versión nueva para que su build siga funcionando sobre una base anterior.
Ese detalle explica por qué el asunto importa más allá de GrapheneOS. Un sistema Android se apoya en tres capas que se mueven a ritmos distintos: el árbol común que Google publica para todo el mundo, los componentes específicos del chip y del dispositivo, y los parches de seguridad mensuales. Cuando las APIs nuevas y los arreglos del mes se quedan durante un trimestre en el canal de Pixel, cualquier proyecto que compile desde AOSP trabaja con un calendario que no controla y con una ventana de exposición mayor de la que sugiere el boletín de seguridad.
Quién depende de esto
GrapheneOS se distribuye habitualmente para dispositivos Pixel, precisamente porque son los que reciben antes el soporte de firmware y las funciones de seguridad por hardware. Eso lo deja en una posición incómoda: depende de la plataforma que ahora critica. Si el diagnóstico es correcto y el retraso se repite con cada QPR, el problema ya no es un desajuste puntual, sino que el ritmo del AOSP queda supeditado a la cadencia de las entregas de Pixel.
Para quien mantiene flotas Android, builds derivadas del AOSP o incluso imágenes para hardware industrial, la consecuencia práctica es la misma: la fecha en la que puede parchear no la marca el boletín mensual, sino cuándo Google decide abrir la mano. Y si eso ocurre en diciembre, como sostiene el proyecto, hay una ventana de tres meses que cada organización tendrá que decidir cómo cubre, si es que puede.
El próximo punto de control es QPR2. Ahí se verá si las APIs llegan al árbol común y si los parches de septiembre salen de su confinamiento, o si el desfase se convierte en la forma normal de funcionar.
