GrapheneOS corrige la regresión crítica de Android 17 en Pixels

Android 17 QPR1 llegó a los Pixel con un bug grave y GrapheneOS ya lo arregló

Android 17 QPR1 se liberó el 15 de septiembre para los Pixel y, según GrapheneOS, trae una regresión severa en el árbol de drivers del kernel de Pixel que provoca parpadeos, lag y cierres completos del sistema bajo presión de memoria. El proyecto open source publicó su propio parche el mismo día de su release del 2 de octubre, antes de que Google haya movido ficha.

«Esto es tan severo que está provocando que se maten procesos por stalls», escribió el equipo de GrapheneOS en su foro. «No está claro cuándo Google lanzará el fix. Diciembre de 2026 no sería sorpresa». El commit está disponible en el repositorio público kernel_pixel_6.6 de GrapheneOS en GitLab.

Qué hace exactamente la regresión

Según el reporte del proyecto, el problema vive en el driver tree del kernel para Pixel incluido con Android 17 QPR1. Cuando el sistema entra en presión de memoria —situación común al alternar entre apps pesadas o con muchas pestañas en segundo plano— el dispositivo experimenta tres modos de fallo:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Stuttering y lag en animaciones, transiciones y gestos.
Cierres forzosos de apps provocados por stalls detectados a nivel de kernel.
Bloqueos completos del sistema en los casos más severos.

El equipo aclara que la regresión también afecta a quienes corren GrapheneOS, porque ellos también actualizaron firmware y drivers a la versión de Google. La diferencia es que, en lugar de esperar el fix upstream, lo parchearon ellos mismos y lo distribuyeron a su base de usuarias y usuarios.

El patrón de Google: 2 a 3 meses para resolver lo crítico

El caso del Pixel 11 ilustra el problema estructural que GrapheneOS viene señalando. La serie Pixel 11 recibió a principios de septiembre de 2026 un bug fix release con el nivel de parche 2026-09-01, pero esa actualización no era Android 17 QPR1 y tampoco incluía los parches de seguridad de firmware y drivers de septiembre. «Quizás lo detectaron y cancelaron», sugiere el proyecto.

GrapheneOS resume así la dinámica que ve en Google:

Las actualizaciones estándar de Android y Pixel tienen un problema severo de demoras. Normalmente toma 2-3 meses para que Google publique fixes tanto para regresiones severas como para temas de seguridad. A menudo tienen los issues resueltos en días, pero el release engineering y el proceso de testing está completamente roto.

Y remata: los lanzamientos mayores, incluido Android 17 QPR1, pasan por un largo período de pruebas público. «Típicamente toma a Google al menos unas 4 a 6 semanas para publicar fixes incluso para los issues más severos. O cancelan el lanzamiento (Pixel 11) o publican un lanzamiento roto (todo lo demás)».

GrapheneOS asume el control de calidad del SO completo

La parte quizá más relevante para founders viene cuando el equipo reconoce públicamente que su carga de trabajo se está expandiendo. Antes su rol era mantener una ROM alternativa sobre AOSP; ahora están haciendo «actualizaciones básicas, testing y control de calidad del sistema operativo entero», algo que históricamente correspondía a Google.

«Tenemos recursos creciendo rápido y lo vamos a manejar», afirma el proyecto. La crítica de fondo apunta a un modelo donde Google controla cada vez más APIs de Android y la posibilidad de parchearlas de forma independiente. Android Authority reportó el 16 de septiembre que GrapheneOS acusó a Google de «gatekeeping» sobre features y parches de seguridad de Android 17: QPR1 sería, según el proyecto, la primera release desde la era Honeycomb en introducir nuevas APIs de desarrollador sin publicarlas a través de AOSP al mismo tiempo, y Google retendría parches para componentes estándar hasta la llegada de QPR2 en diciembre.

Bonus técnico: menos RAM antes de noviembre

Aprovechando la auditoría que les obligó a hacer la regresión, GrapheneOS detectó que podía eliminar la mayor parte del consumo extra de memoria de su función secure spawning, sin penalizaciones funcionales relevantes. Planean publicar esa mejora antes de noviembre de 2026, lo que debería traducirse en menos presión de memoria en cargas intensivas, en paralelo con el fix del kernel.

GrapheneOS sale del corral de Pixel: Motorola Signature 27 en 2027

La misma semana del anuncio del fix, el 24 de septiembre, GrapheneOS confirmó que el Motorola Signature 27 será el primer teléfono no-Pixel soportado oficialmente. Según Android Authority, llevará el Snapdragon 8 Elite Extreme Gen 6 y promete 7 actualizaciones de SO y hasta 7 años de parches de seguridad. Digital Trends añadió que la alianza apunta a un lanzamiento en 2027, con precios por encima de la línea Pixel —el Pixel 11 parte de USD 900 y el Pixel 11 Pro XL llega a USD 1.300, según el mismo medio.

Para founders, eso significa una segunda vía de hardware para una de las ROM más respetadas en seguridad móvil, sin tener que comprar un Pixel.

Qué significa esto para tu startup

Si tu equipo entrega Pixels corporativos o apps que corren sobre Android gestionado, este caso deja tres acciones concretas:

Añade un test de regresión de kernel a tu proceso de QA Android antes de empujar updates del sistema operativo. Una release puede pasar los test suites de Google y aun así romper apps bajo presión de memoria. Considera correr tu app en escenarios de baja memoria como parte del smoke test post-OS-update, especialmente en los días siguientes a un Pixel Drop.
Evalúa GrapheneOS o un fork robusto de AOSP para despliegues de alta sensibilidad. Si manejas datos sensibles, pilotar un dispositivo con GrapheneOS deja de ser cosa de entusiastas. Con la llegada de Motorola en 2027, el lock-in con Pixel se reducirá y podrás elegir hardware en función del threat model, no de la disponibilidad.
Documenta la dependencia con los tiempos de Google en tu plan de continuidad de negocio. El patrón «fix disponible en días, release en meses» es estructural. Presupuesta en tu roadmap al menos un trimestre de fragilidad tras cada Pixel Drop importante, y mantén un canal alternativo para usuarias y usuarios críticos que no pueden esperar al parche oficial.