Pixel esclusi da AOSP: la community Android è furiosa. Cosa sta succedendo davvero

A fine marzo 2025, abbiamo presentato la nuova strategia perseguita dall’azienda di Mountain View: Google chiude lo sviluppo di Android, spostandolo prevalentemente su un ramo interno privato. Lo scopo dichiarato è quello di semplificare le operazioni e razionalizzare la gestione del codice. La notizia ha inizialmente sollevato timori all’interno della community open source e degli sviluppatori di custom ROM, che hanno intravisto il rischio di una progressiva chiusura del progetto AOSP (Android Open Source Project). Google, da parte sua, ha rassicurato tutti: AOSP continuerà ad esistere. Tuttavia, alcuni segnali concreti — tra cui la rimozione di elementi chiave per lo sviluppo su dispositivi Pixel — stanno già rendendo la vita molto più difficile a chi lavora sull’ecosistema Android al di fuori di Google.

Il nodo AOSP: codice aperto, ma sempre più limitato

AOSP è il progetto open source curato da Google che costituisce la base del sistema operativo Android. Comprende il codice sorgente “puro” di Android, senza le personalizzazioni e i servizi proprietari di Google (come il Play Store o i Google Play Services).

Lo scopo di AOSP è fornire a produttori, sviluppatori e comunità open source una piattaforma libera su cui costruire le proprie versioni di Android — come ad esempio le custom ROM (LineageOS, GrapheneOS, e così via), i firmware per dispositivi specifici e sviluppare personalizzazioni aziendali.

Tuttavia, per creare una versione funzionante di Android per un determinato dispositivo, AOSP da solo non basta: servono anche componenti specifici come il device tree, i driver binari e il codice del kernel adattato all’hardware. Google forniva questi elementi per i dispositivi Pixel, ma con Android 16, rilasciato a metà giugno 2025, ha iniziato a sottrarli alla community.

Sebbene Android 16 sia stato regolarmente pubblicato su AOSP sotto licenza Apache 2.0, la mancanza dei citati componenti fondamentali ha allarmato gli sviluppatori.

Le device tree sono essenziali per compilare correttamente un sistema Android per uno specifico dispositivo: definiscono l’hardware, i file proprietari necessari e altri parametri critici. La loro assenza costringe i maintainer di ROM a utilizzare versioni vecchie o, peggio ancora, a dover ricorrere a pratiche di reverse engineering.

In parallelo, il kernel rilasciato da Google per Android 16 presenta una cronologia compressa in un singolo commit, rendendo impossibile tracciare le modifiche, integrarne selettivamente porzioni in altri progetti o studiarne l’evoluzione. Questa pratica compromette un’attività che, in passato, era fondamentale per la manutenzione e l’ottimizzazione di device basati su SoC simili.

Addio Pixel come riferimento AOSP: arriva Cuttlefish

Seang Chau, Vicepresidente e General Manager della piattaforma Android, ha confermato su X che “AOSP non sta per scomparire”. Tuttavia, ha ribadito che i Pixel non saranno più il target di riferimento del progetto. D’ora in avanti, Google promuoverà Cuttlefish, un dispositivo virtuale eseguibile su PC, come nuovo standard per le build di AOSP.

La mossa è coerente con la visione di AOSP come piattaforma neutra rispetto all’hardware, pensata per vendor di SoC, OEM e sviluppatori. Tuttavia, Cuttlefish — pur utile in fase di test — non può replicare fedelmente il comportamento dell’hardware reale. E per chi vuole portare Android su dispositivi fisici, come i Pixel, il lavoro diventa inevitabilmente molto più gravoso.

La presa di posizione di Chau, sostengono alcuni osservatori, non risponde però a una domanda importante: le versioni AOSP di Android per i device Pixel non saranno comunque più distribuite o arriveranno più tardi?

Molte persone hanno infatti acquistato i Pixel come piattaforme di sviluppo o utilizzano i loro sorgenti come riferimento per sviluppare aggiornamenti personalizzati dei dispositivi a ogni versione di Android.

La risposta di Chau è evidentemente diretta ai responsabili di GrapheneOS che sostenevano di aver ricevuto conferma della chiusura di AOSP.

ROM personalizzate: una sfida tecnica in crescita

La comunità delle custom ROM — progetti come LineageOS, GrapheneOS, CalyxOS (che ha pubblicato una nota in merito alle recenti novità) — si trova davanti a un cambio di rotta davvero marcato. Nolen Johnson, contributore storico di LineageOS, ha definito la situazione “dolorosa”. Mentre prima bastava adattare i device tree ufficiali forniti da Google, ora sarà necessario ricostruirli da zero. Questo significa fare reverse engineering, test continui, e scontrarsi con binari e kernel “opachi”.

Di fatto, i Pixel sono adesso “declassati” allo stesso livello degli altri dispositivi Android di terze parti, sui quali i developer hanno sempre dovuto affrontare la mancanza di trasparenza del codice e il supporto limitato dei produttori.

In un altro articolo ci siamo chiesti se sia sicuro aggiornare Android con una ROM personalizzata.

Un cambiamento che pesa, ma non un tradimento dell’open source

Google, va detto, non ha alcun obbligo legale di pubblicare i device tree, i binari o la cronologia completa del kernel. Anzi, è stata per anni l’eccezione virtuosa nel panorama Android, offrendo aperture che altri produttori non si sono mai sognati di concedere.

Questo comportamento ha permesso la nascita e la sopravvivenza di un intero ecosistema parallelo di sistemi Android personalizzati e ottimizzati, oggi messi in discussione da un cambio di rotta che, pur legittimo, ha effetti concreti e negativi per quella stessa community. E potrebbe averli anche per Google stessa, con i Pixel che sembrano essere considerati al pari di tutti gli altri prodotti.

Il passaggio a Cuttlefish favorirà il lavoro degli sviluppatori che si concentrano sul core della piattaforma Android piuttosto che sull’hardware consumer, ma allontana Google dalla community di utenti avanzati e sviluppatori indipendenti che hanno storicamente contribuito a far evolvere Android anche al di fuori dei circuiti ufficiali.