Google pubblicherà il codice Android solo due volte l’anno

Il modello trunk stable mantiene le patch mensili, ma il codice sarà visibile solo dopo la pubblicazione

Lo scorso 6 ottobre, il bollettino di aggiornamento Pixel di ottobre 2026 è stato pubblicato con una riga che vale più di molte patch: a partire dal 2026, per allinearsi al modello di sviluppo trunk stable, il codice sorgente verrà pubblicato su AOSP nel secondo e nel quarto trimestre. È lì, in quel passaggio tra una vulnerabilità Bluetooth critica e le correzioni di Framework e System, che si gioca la vera partita sul controllo dell’ecosistema Android.

Il bollettino non porta solo correzioni. I livelli di patch di sicurezza 2026-10-05 o successivi risolvono tutte le problematiche elencate nel documento e tutti i problemi del bollettino di sicurezza Android di ottobre; tutti i dispositivi Google supportati riceveranno un aggiornamento al livello 2026-10-05. Nella lista delle vulnerabilità compare CVE-2026-55330, un problema di elevazione dei privilegi classificato critico nel componente Bluetooth. Ma la novità strutturale è un’altra, e sta in una frase che in un bollettino di sicurezza non dovrebbe trovare spazio: il codice sorgente non arriverà più con cadenza continua, ma solo due volte l’anno.

Il dettaglio non è marginale. Chi sviluppa su AOSP dovrà aspettare il secondo o il quarto trimestre per vedere il codice, con un intervallo che in alcuni casi può superare il trimestre. La scelta di inserire l’annuncio dentro un bollettino di sicurezza non è neutra: chi cerca le patch trova anche la nuova cadenza, ma chi non arriva in fondo al documento rischia di scoprire il cambiamento solo quando il codice smette di comparire. E la domanda resta aperta: perché un bollettino di sicurezza deve occuparsi del calendario di rilascio del codice sorgente? La risposta sta nel passaggio al modello trunk stable, avviato ben prima di ottobre.

Trunk stable: chi guadagna dal codice a scadenza semestrale

Il punto di svolta è anteriore al bollettino. Già dal 27 marzo 2025 il ramo di rilascio più recente è referenziato dal nuovo manifest android-latest-release, utilizzabile direttamente con Repo, e per compilare e contribuire ad AOSP si deve usare proprio android-latest-release. La transizione tecnica era già avvenuta; il bollettino di ottobre la formalizza sul piano del calendario: dal 2026 niente più rilascio continuo del codice, ma una finestra semestrale.

La logica dichiarata da Google è una logica di semplificazione. La ricostruzione offerta da LWN riassume il ragionamento di Google: il rilascio semestrale semplifica lo sviluppo, elimina la complessità della gestione di più rami di codice e consente di fornire codice più stabile e sicuro agli sviluppatori della piattaforma Android. Chi produce ci guadagna: un solo ramo trunk stable riduce i costi di manutenzione e il rischio di regressioni. Chi sta a valle, invece, perde l’accesso tempestivo al codice su cui costruisce i propri fork e su cui imposta la verifica indipendente.

Nel frattempo il flusso delle patch non rallenta: gli aggiornamenti di sicurezza Android di ottobre risolvono 25 vulnerabilità nei componenti Framework e System, come dettagliato da SecurityWeek. È esattamente il paradosso: le correzioni viaggiano più veloci del codice che le contiene. Se il codice arriva a rilascio avvenuto, la trasparenza promessa diventa una verifica posticipata per definizione. Per chi fa sicurezza, il costo non è teorico: una vulnerabilità scoperta dopo la pubblicazione semestrale può restare non verificabile per settimane, in attesa della finestra successiva. Google può sostenere che il codice sia più stabile; meno sostenibile è l’idea che sia altrettanto trasparente quando arriva dopo i fatti.

Cosa resta aperto se il codice arriva dopo le patch?

Google ha ribadito — sempre secondo quanto riferito da LWN — che il suo impegno verso AOSP è invariato e che il nuovo calendario di rilascio aiuta a costruire una base più solida e sicura per l’ecosistema Android. Ma se la base è più solida solo perché la verifica esterna è rimandata, cosa resta davvero dell’impegno? La promessa di maggiore stabilità regge finché non emerge un problema critico in un codice che nessuno, fuori da Google, può ispezionare per mesi. La prossima pubblicazione del codice su AOSP, attesa nel quarto trimestre, mostrerà se la trasparenza è un costo che Google è ancora disposta a pagare, o solo una promessa rinnovata in un bollettino di sicurezza.