I più attenti e smanettoni di voi ormai avranno preso nota del fatto che il codice del kernel dei Pixel non si scaricherebbe più liberamente da un repository pubblico come succedeva fino a poco tempo fa.
I Google Pixel avevano sempre rappresentato un’eccezione tra gli smartphone Android proprio per questo visto che gli sviluppatori potevano ispezionare il software, provare build sperimentali e installare sistemi alternativi come GrapheneOS con una libertà che nessun altro produttore garantiva davvero, di cui avevamo già raccontato l’annuncio della partnership con Motorola lo scorso ottobre e poi confermato nei dettagli lo scorso marzo, quando erano emersi i primi dispositivi Snapdragon pensati proprio per affrancarsi dall’hardware Google.
Ora, però, sembra che un cambiamento silenzioso nella gestione del codice sorgente Pixel stia rischiando di intaccare proprio questa nomea.
Indice:
Segui TuttoAndroid su Google Discover
Cosa ha segnalato GrapheneOS
Il team di GrapheneOS ha denunciato su X che Google avrebbe eliminato il download pubblico e immediato del codice dei driver Pixel, sostituendolo con un modulo di richiesta manuale: bisogna compilare un Google Form e aspettare che qualcuno risponda con un link a Google Drive. Un’operazione che prima richiedeva un paio d’ore, oggi arriva a costare settimane intere di attesa.
Le ROM personalizzate dipendono da due elementi separati: il sistema operativo alternativo vero e proprio, come GrapheneOS, e il kernel, cioè il livello di codice che collega l’hardware del telefono al software che ci gira sopra. Google è vincolata per legge, tramite la licenza open source GPLv2, a rilasciare pubblicamente il codice del kernel.
Google replaced pushing Git tags for certain source code with obtaining source code via Google Drive after making a request through Google Forms. It’s completely ridiculous and they’ve gradually become very slow at handling requests. They’re in clear violation of the GPLv2 now.
— GrapheneOS (@GrapheneOS) August 8, 2026
Fino a poco tempo fa lo faceva con aggiornamenti automatici su una piattaforma aperta; ora, stando a GrapheneOS, gli sviluppatori devono richiederlo manualmente e attendere settimane per un link Drive, oltretutto ricevendo la cronologia degli aggiornamenti compressa in un unico file poco leggibile.
Senza un kernel aggiornato una ROM personalizzata semplicemente non funziona, quindi il problema si moltiplica su due fronti perché chi lavora sul kernel perde la possibilità di seguire passo passo le correzioni ai bug, mentre i progetti come GrapheneOS restano bloccati per settimane prima di poter rilasciare le proprie patch di sicurezza.
In pratica, tutta la catena di lavoro che porta un aggiornamento Android fino agli utenti di queste ROM finisce per rallentare drasticamente.
Segui Google su Telegram, ricevi news e offerte per primo
Chi possiede un Pixel potrebbe non accorgersene
Chi usa Android così com’è arriva dritto da Google, senza toccare nulla, non noterà alcun cambiamento visto che in fin dei conti gli aggiornamenti software e le patch di sicurezza continueranno ad arrivare puntuali come sempre.
Il problema riguarda invece chi compra un Pixel proprio per installarci GrapheneOS o sistemi simili orientati alla privacy: allora in questi casi gli aggiornamenti di sicurezza arriveranno più tardi, perché queste ROM hanno sempre avuto bisogno del codice in anticipo per testarlo e adattarlo.
C’è poi un problema di trasparenza, dato che senza una cronologia chiara del codice diventa più complicato anche per i ricercatori di sicurezza indipendenti capire cosa Google stia effettivamente modificando.
E in generale i Pixel perdono terreno proprio sul fronte sviluppatori, mentre altri produttori ne guadagnano: GrapheneOS ha fatto notare che la propria futura collaborazione con Motorola non soffrirà di questi rallentamenti.
Il team ha comunque precisato che il problema riguarda solo i Pixel, non Android in generale, e non toccherà i futuri telefoni Motorola compatibili con GrapheneOS. Anzi, secondo lo stesso team, è proprio la difficoltà crescente nel lavorare con i Pixel ad aver spinto GrapheneOS verso Motorola, che ospiterà il proprio codice in autonomia, bypassando del tutto le procedure di approvazione Google.
Una tendenza che va avanti da un po’
Questo passo si inserisce in un percorso già avviato da tempo visto che Google era già passata a rilasciare il codice sorgente AOSP solo due volte l’anno, spostando sempre più sviluppo dietro le quinte fino alle release principali.
Fino a qualche anno fa Google faceva anzi il contrario e pubblicava non solo il kernel richiesto dalla licenza, e molto altro materiale che non era neppure obbligata a condividere. Il motivo era che il Pixel funzionava da riferimento ufficiale per AOSP, quindi serviva che gli sviluppatori potessero lavorarci sopra senza intoppi.
Con Android 16 Google ha spostato questo ruolo di riferimento su un dispositivo virtuale chiamato Cuttlefish, smettendo di fornire device tree e binari per i Pixel, e ora sta chiudendo anche l’accesso rapido al kernel.
Di fatto, il Pixel ha perso il vantaggio che lo distingueva dagli altri telefoni Android sul fronte sviluppo. L’unico motivo rimasto per sceglierlo, guardando la faccenda dal punto di vista di chi programma, resta la relativa facilità con cui si può sbloccare il bootloader e la disponibilità delle immagini di fabbrica ufficiali.