Google cambia le regole di Android: AOSP passa a due release l’anno, cosa significa

La pubblicazione del codice sorgente Android attraverso il programma Android Open Source Project (AOSP) ha un impatto profondo sul flusso di lavoro degli sviluppatori indipendenti e dei produttori di dispositivi. AOSP e il codice sorgente Android rimangono il cuore della piattaforma, ma Google ha annunciato che a partire dal 2026 le nuove versioni saranno pubblicate solo due volte l’anno, nel secondo e quarto trimestre (Q2 e Q4).

Si tratta di un cambio di rotta che influenza direttamente la sincronizzazione dei rami, le pratiche di integrazione dei vendor e le scadenze dei progetti di sistema, oltre a richiedere nuove abitudini operative.

Feroci critiche si erano sollevate già dopo la notizia di una maggiore chiusura dello sviluppo di Android: i temi che emergono sono la complessità nella gestione dei rami, la necessità di riorganizzare pipeline CI/CD e l’impatto sulle ROM personalizzate e alternative. Occorre infatti considerare come la scelta di Google interagisca con le attuali pratiche di rilascio trimestrale e con gli strumenti di integrazione continua usati da OEM, sviluppatori di ROM e integratori di sistema.

Cosa cambia nella roadmap di pubblicazione AOSP

Come spiegato nell’introduzione, la novità principale è che le pubblicazioni del codice sorgente AOSP saranno concentrate in due finestre annuali: Q2, che corrisponde al rilascio maggiore, e Q4, dedicato a un aggiornamento minore ma con cambiamenti rivolti agli sviluppatori.

In passato Google pubblicava i sorgenti di Android a cadenza trimestrale; la nuova policy riduce questo numero a due per semplificare, a detta dei portavoce di Mountain View, la gestione dei rami e migliorare la stabilità.

Google raccomanda esplicitamente l’utilizzo del ramo android-latest-release invece di aosp-main, mentre il manifest aosp-latest-release rifletterà sempre l’ultimo rilascio presente su AOSP, agevolando chi sviluppa e contribuisce al progetto.

Per chi gestiscemirror, fork o integrazioni upstream, la differenza si traduce in finestre di sincronizzazione più ampie e meno frequenti ma allo stesso tempo più significative.

Motivazioni tecniche: trunk-stable e gestione dei rami

La decisione di Google è motivata dalla volontà di allineare le pubblicazioni al modello di sviluppo trunk-stable che privilegia una linea principale stabile su cui effettuare integrazioni continue e rilasciare snapshot.

Con un flusso di rilasci più diluiti nel tempo, per i tecnici Google diventa più semplice mantenere la coerenza tra il trunk (ramo principale di sviluppo del codice, quello su cui confluiscono tutte le modifiche valide e da cui vengono derivati i vari branch) e i rami di rilascio, riducendo il rischio di regressioni dovute alla gestione simultanea di molteplici branch attivi.

Per esempio, i team di integrazione dei produttori spesso devono unire patch di sicurezza, driver e personalizzazioni vendor in rami diversi: ridurre il numero di rilasci permette di limitare i punti di merge, cioè le fasi in cui il codice proveniente da rami diversi deve essere integrato, riducendo così la complessità complessiva.

Anche le pipeline CI, ovvero i sistemi di integrazione continua che compilano automaticamente l’intero sistema Android ed eseguono test automatici a ogni modifica rilevante, traggono vantaggio da una minore frammentazione dei branch, perché si possono pianificare test di integrazione più approfonditi durante le finestre di rilascio.

L’approccio, tuttavia, richiede una gestione molto rigorosa del trunk principale e una strategia di backporting ben definita per le patch critiche che devono essere applicate anche a branch di versioni precedenti.

Impatto pratico per sviluppatori, OEM e progetti open source

Per gli sviluppatori di applicazioni e per i team che mantengono fork di Android, la concentrazione delle release in Q2 e Q4 richiede una ridefinizione delle finestre di test e delle strategie di compatibilità.

Team come quelli delle ROM personalizzate o di progetti di integrazione hardware (ad esempio chi adatta kernel e driver per nuovi SoC) devono anticipare l’inserimento delle modifiche.

I produttori OEM traggono vantaggio da una base di codice meno frammentata perché l’integrazione del codice proprietario può essere pianificata in due cicli principali, riducendo i costi di merge e manutenzione. Al contrario, progetti che si basano su rilasci frequenti per introdurre innovazioni incrementali potrebbero dover riorganizzare i loro branch di sviluppo interni e usare strategie nuove per mantenere agilità.

Sicurezza e manutenzione delle patch

La politica di riduzione dei rilasci legati alle versioni AOSP non influisce sul processo di pubblicazione delle patch di sicurezza: Google continuerà a pubblicare aggiornamenti di sicurezza ogni mese su un ramo dedicato esclusivamente alla correzione dei problemi critici.

Ciò significa che gli operatori che mantengono dispositivi o fork commerciali continueranno a ricevere e integrare patch di sicurezza con la stessa frequenza, senza attendere le due finestre principali di rilascio.

Nonostante ciò, la convivenza tra un ciclo semestrale per i rilasci del sorgente AOSP e un ciclo mensile per le patch richiede processi di backport robusti e strumenti che automatizzino l’applicazione selettiva delle correzioni alle versioni supportate. Per esempio, un produttore che mantiene una release Android stabile per un’intera famiglia di dispositivi dovrà continuare a mantenere un ramo di sicurezza aggiornato e a testare i backport in ambienti CI separati per garantire che le patch non introducano problemi.