In questo articolo Indice dei contenuti 2 sezioni
Chi sviluppa software alternativo sui Pixel si è accorto che qualcosa è cambiato, e non in meglio: Google ha modificato in silenzio il modo in cui distribuisce il codice sorgente del kernel dei suoi smartphone, trasformando un download pubblico e automatico in una procedura burocratica con tempi di attesa che ormai si contano in settimane. Nessun annuncio, nessuna nota ufficiale. Solo un passaggio in più, che però pesa parecchio su chi lavora con le ROM alternative.
Il caso è stato sollevato dal team di GrapheneOS, che ha raccontato la vicenda su X. La sostanza è semplice: il codice del kernel dei Pixel non finisce più su piattaforme pubbliche con aggiornamenti automatici. Per ottenerlo serve compilare un Google Form, poi attendere che qualcuno risponda inviando un link a Google Drive. Prima bastavano poche ore, adesso possono servire settimane.
Perché il kernel non è un dettaglio tecnico
Vale la pena spiegare cosa sia il kernel, per capire la portata della faccenda. È lo strato di codice che permette al software di dialogare con l’hardware del telefono. Senza un kernel aggiornato, una ROM come GrapheneOS non riesce a funzionare come si deve su un Pixel nuovo o su una versione recente di Android. Il risultato è una catena che si allunga: Google rilascia un aggiornamento di sicurezza, GrapheneOS deve attendere il codice, testarlo e solo dopo distribuire la patch ai propri utenti. Nel frattempo, chi ha installato una ROM alternativa resta esposto a vulnerabilità che Google ha già chiuso da tempo sui dispositivi standard.
C’è poi un secondo aspetto, più tecnico ma altrettanto rilevante. Google non fornisce più la cronologia completa dei commit, cioè lo storico delle singole modifiche al codice. Tutto viene compresso in un unico file, complicato da analizzare. Per chi costruisce software di sicurezza quella cronologia è oro: permette di capire cosa è stato cambiato e per quale motivo. Senza di essa, una verifica indipendente diventa quasi impraticabile.
Da un punto di vista strettamente legale non c’è nulla di irregolare. Google è tenuta a pubblicare il codice del kernel, che ricade sotto la licenza open source GPLv2. Il punto non è se lo rilasci, ma come. Un modulo da compilare e un link Drive rispettano la lettera della licenza, ma svuotano lo spirito con cui quella licenza è nata.
Il Pixel non è più il telefono degli sviluppatori
Il quadro generale aiuta a leggere meglio la mossa. Google ha già portato il ciclo di rilascio di AOSP a due volte l’anno, spostando una fetta crescente dello sviluppo di Android dietro porte chiuse. Ha inoltre interrotto la pubblicazione di device tree e driver binari per i Pixel, materiale che in passato veniva distribuito spontaneamente proprio perché quei telefoni erano la piattaforma di riferimento per la comunità. Quella vetrina aperta, oggi, è parecchio più stretta.
Non sorprende quindi che GrapheneOS abbia accelerato su un altro fronte. Il team ha spiegato che questa situazione ha spinto in avanti la partnership con Motorola: i nuovi telefoni Motorola con GrapheneOS preinstallato non soffriranno del problema, perché sarà Motorola a gestire direttamente il codice senza passare dai processi di approvazione di Google. La rottura dell’esclusiva storica con i Pixel arriva esattamente in questo momento, e la coincidenza dice molto.
Per chi tiene un Pixel con Android standard, nel breve periodo non cambia niente. Le patch di sicurezza continueranno ad arrivare con la solita cadenza. Il discorso è diverso per chi ha scelto quei dispositivi proprio per la libertà di installare software alternativo: lo spazio si sta restringendo un pezzo alla volta, senza comunicati e senza dibattito.
Restano due vantaggi concreti rispetto agli altri Android, sempre guardando dalla parte degli sviluppatori: la facilità con cui si sblocca il bootloader e la disponibilità delle factory image. Non è poco, però è molto meno di quanto offriva la stessa piattaforma solo qualche anno fa.
