Vai al contenuto
Offerte

Google Pixel, Google blocca il codice del kernel: ROM a rischio

In questo articolo Indice dei contenuti 3 sezioni

Chi mette le mani nel software dei telefoni lo ha notato subito: creare ROM personalizzate per i Pixel è diventato improvvisamente più complicato, perché il codice del kernel non si scarica più liberamente da un repository pubblico come accadeva fino a poco tempo fa. Un cambiamento arrivato senza annunci, senza comunicati, ma con conseguenze molto concrete per chi lavora su sistemi alternativi. Fino a ieri i telefoni di Google rappresentavano l’eccezione nel panorama Android. Gli sviluppatori potevano ispezionare il software, provare build sperimentali, installare sistemi alternativi con una libertà che nessun altro produttore garantiva sul serio. Ora quella nomea rischia di sgretolarsi.

La segnalazione di GrapheneOS e il nodo della licenza

Il team di GrapheneOS ha denunciato pubblicamente su X, l’8 agosto 2026, che Google avrebbe eliminato il download immediato del codice dei driver Pixel, sostituendolo con una procedura manuale. Va compilato un Google Form, poi si aspetta che qualcuno risponda con un link a Google Drive. Un’operazione che prima richiedeva un paio d’ore adesso può costare settimane di attesa. Secondo il team, si tratta di una violazione chiara della GPLv2, la licenza open source che obbliga Google a rendere pubblico il codice del kernel.

Vale la pena chiarire come funziona la faccenda, perché ci sono due pezzi distinti in gioco. Da un lato il sistema operativo alternativo vero e proprio, GrapheneOS per esempio. Dall’altro il kernel, cioè lo strato di codice che fa dialogare l’hardware del telefono con tutto quello che gira sopra. Senza un kernel aggiornato una ROM personalizzata non funziona, punto. E il problema si moltiplica su due fronti: chi lavora sul kernel non riesce più a seguire passo passo le correzioni ai bug, mentre progetti come GrapheneOS restano fermi settimane prima di poter rilasciare le patch di sicurezza. C’è anche un dettaglio fastidioso, cioè la cronologia degli aggiornamenti che arriva compressa in un unico file poco leggibile.

Chi se ne accorgerà e chi no

Per chi usa Android così come esce dalla fabbrica, senza modificare nulla, non cambierà assolutamente niente. Aggiornamenti software e patch di sicurezza continueranno ad arrivare puntuali. Il discorso si fa diverso per chi acquista un Google Pixel proprio per installarci sopra sistemi orientati alla privacy: in quel caso gli aggiornamenti di sicurezza arriveranno in ritardo, perché queste ROM hanno sempre avuto bisogno del codice in anticipo per testarlo e adattarlo. Poi c’è la questione trasparenza. Senza una cronologia chiara delle modifiche diventa più difficile anche per i ricercatori di sicurezza indipendenti capire cosa Google stia effettivamente cambiando sotto il cofano.

Il team di GrapheneOS ha precisato che il problema riguarda soltanto i Pixel, non Android nel suo complesso, e che i futuri telefoni Motorola compatibili non ne soffriranno. Anzi, è stata proprio la crescente difficoltà nel lavorare con i dispositivi Google a spingere il progetto verso Motorola, che ospiterà il codice in autonomia saltando del tutto le procedure di approvazione. La partnership era stata annunciata lo scorso ottobre e confermata nei dettagli a marzo, quando erano emersi i primi dispositivi Snapdragon pensati per affrancarsi dall’hardware Google.

Una direzione presa da tempo

Questa mossa non nasce dal nulla. 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. Qualche anno fa la logica era opposta: veniva pubblicato non solo il kernel richiesto dalla licenza ma anche molto altro materiale, senza alcun obbligo. Il motivo era semplice, il Pixel funzionava da riferimento ufficiale per AOSP e serviva che gli sviluppatori potessero lavorarci sopra senza intoppi.

Con Android 16 quel ruolo di riferimento è passato a un dispositivo virtuale chiamato Cuttlefish, mentre device tree e binari per i Pixel hanno smesso di essere forniti. Adesso si chiude anche l’accesso rapido al kernel. Per chi programma, l’unico vantaggio rimasto è la relativa facilità con cui si sblocca il bootloader e la disponibilità delle immagini di fabbrica ufficiali.

Condividi:
43 Condivisioni