Código fuente bajo demanda y historial de commits con un clic: Google cambia discretamente las reglas para GrapheneOS

A los desarrolladores de GrapheneOS les resulta más difícil obtener parte del código fuente para los teléfonos Google Pixel. Google dejó de publicar automáticamente algunos componentes a través de Git y trasladó su distribución a solicitudes manuales. El equipo tiene que completar un formulario de Google, indicar los materiales necesarios y esperar un enlace a un archivo en Google Drive. Según GrapheneOS, antes los archivos necesarios solían aparecer en cuestión de horas, y ahora la espera a veces se prolonga por semanas.

Los cambios afectan al código fuente de los controladores del kernel de Pixel, que GrapheneOS necesita para dar soporte a los teléfonos Google. Antes Google publicaba nuevas versiones en repositorios Git y añadía etiquetas relacionadas con lanzamientos concretos. Los desarrolladores podían recoger de inmediato la versión necesaria, compararla con la anterior y ver la secuencia de correcciones aplicadas. Tras Android 16, Google dejó de enviar a Git etiquetas para parte de los orígenes, por lo que GrapheneOS recibe las versiones correspondientes en forma de archivos.

Al mismo tiempo cambió la historia de desarrollo. En los repositorios de los controladores del kernel de Pixel para Android 16, Google combinó muchos cambios previos en un único commit. A esa práctica se la conoce como consolidación de la historia de commits. Los archivos del código fuente se conservan, pero desaparece la cadena detallada de ediciones: el desarrollador ya no puede abrir el historial y determinar rápidamente en qué commit se corrigió un error concreto, qué líneas cambiaron junto con la corrección y por qué los desarrolladores introdujeron la modificación. Para el mantenimiento de código sistémico complejo, un historial detallado facilita notablemente el análisis de las actualizaciones.

GrapheneOS depende especialmente del acceso puntual a los componentes de bajo nivel de Pixel. El proyecto no se limita a modificar la interfaz de Android ni a eliminar servicios de Google. Los desarrolladores compilan sus propias versiones del kernel, aplican correcciones, añaden mecanismos de protección y verifican el funcionamiento de los componentes de hardware tras las actualizaciones. Cuando aparece una nueva versión de firmware, el equipo debe comparar el código fuente con el lanzamiento anterior, compilar el sistema y comprobar si los cambios han afectado al funcionamiento del hardware o a los mecanismos de seguridad.

El retraso en la publicación de los orígenes también complica el análisis de vulnerabilidades. Una corrección en un controlador puede consistir en apenas unas líneas, pero al desarrollador le interesa comprender el contexto: qué error corrige la modificación, cuándo se cambió el código y qué partes del sistema afectan el parche. El historial completo de Git permite comparar rápidamente commits individuales. Un archivo con la versión final del código también permite compilar el software, pero encontrar la causa de un cambio concreto exige más trabajo manual.

GrapheneOS además plantea objeciones sobre el cumplimiento de la licencia GNU GPL versión 2, o GPLv2. El kernel de Android se basa en Linux, y Linux se distribuye bajo la GPLv2. La licencia exige proporcionar el código fuente correspondiente y define el código fuente como la forma preferente de la obra para introducir cambios. El equipo de GrapheneOS considera que el orden actual de distribución de parte del código de Pixel es problemático desde el punto de vista de los requisitos de la GPLv2.

El mero paso de Git a archivos no prueba una infracción de la licencia. La GPLv2 no obliga al desarrollador a publicar un repositorio con el historial completo de cada commit. La disputa se refiere a la forma y la accesibilidad del material facilitado, y en qué medida el código recibido se ajusta a una forma conveniente para su posterior modificación. Por ello, la supuesta violación de la GPLv2 sigue siendo, por ahora, la postura de GrapheneOS y no un hecho jurídico establecido.

El problema actual continúa cambios anteriores en la publicación del código fuente de Android y Pixel. Tras el lanzamiento de Android 16, Google modificó el calendario de publicaciones del Android Open Source Project, la parte abierta de Android. Las versiones completas mensuales de AOSP cesaron, y las actualizaciones de Pixel empezaron a separarse más del árbol de código abierto público de Android. Los desarrolladores de sistemas alternativos tuvieron que adaptar su proceso de compilación al nuevo orden de publicación del código.

Las consecuencias ya se hicieron patentes al añadir soporte para Pixel 10. GrapheneOS pudo preparar parte de los componentes de bajo nivel, incluido el kernel y el firmware, pero para el soporte completo del teléfono se requería el código de Android 16 QPR1. La publicación de la versión necesaria de AOSP se retrasó, por lo que el equipo no pudo terminar la migración del sistema inmediatamente después de la llegada de la nueva generación de Pixel.

A pesar de la mayor complejidad del trabajo, los Pixel siguen siendo por ahora la principal plataforma de hardware para GrapheneOS. El proyecto exige requisitos bastante estrictos a los teléfonos: el fabricante debe permitir la instalación de un sistema operativo de terceros sin desactivar mecanismos importantes de protección, publicar actualizaciones de seguridad con regularidad, mantener durante mucho tiempo los controladores y el firmware y proporcionar funciones de seguridad por hardware modernas. Durante largo tiempo, los teléfonos Google han cumplido mejor que la mayoría de los dispositivos Android con el conjunto de requisitos de GrapheneOS.

No obstante, la dependencia de un solo fabricante se está reduciendo paulatinamente. En marzo de 2026 GrapheneOS anunció una colaboración a largo plazo con Motorola. Las empresas trabajan conjuntamente en futuros teléfonos cuya plataforma de hardware y software debe cumplir los requisitos de seguridad y privacidad de GrapheneOS. Para los modelos adecuados, los desarrolladores planean soporte oficial de su sistema operativo.

Los primeros teléfonos Motorola compatibles se esperan en 2027. El soporte está pensado para modelos futuros, no para dispositivos Motorola ya comercializados: a los aparatos actuales les faltan algunas capacidades necesarias. En la primera fase, GrapheneOS se centra en plataformas insignia, donde resulta más fácil satisfacer los requisitos del proyecto sobre protección por hardware, actualizaciones prolongadas y funcionamiento de un sistema operativo de terceros.

El paso a Motorola no implica renunciar a los Pixel. GrapheneOS sigue publicando actualizaciones para los teléfonos Google que mantiene. En agosto de 2026 el sistema recibió controladores recientes, firmware y el nivel de parches de seguridad de Pixel del 5 de agosto. La incorporación de un segundo fabricante resuelve otro problema: el desarrollo de GrapheneOS ya no dependerá por completo de las normas con las que Google publica el código fuente y otros componentes para Pixel.