Aggiornamenti A/B su Android: come funzionano gli slot

Gli aggiornamenti A/B sono il motivo per cui il telefono continua a funzionare mentre scarica Android 17 e per cui, alla fine, si riavvia due volte. Chi arriva da un telefono di qualche anno fa se ne accorge subito: non c’è più la schermata nera con la barra di installazione, non c’è più mezz’ora di attesa con il telefono inutilizzabile.

Il meccanismo esiste dal 2016, ma viene ancora raccontato in modo confuso. Qui sotto c’è cosa fa il sistema, dove finiscono i file, perché il Virtual A/B ha cambiato le regole e come controllare su quale slot sta girando il tuo telefono.

Cosa sono gli aggiornamenti A/B e perché esistono

Un telefono con aggiornamenti A/B tiene due copie delle partizioni di sistema. Una è attiva, l’altra è in attesa. Quando arriva un OTA, cioè l’aggiornamento che scarichi direttamente dal telefono, il sistema scrive la nuova versione nella copia inattiva e lascia intatta quella in uso.

Il vantaggio è doppio. Puoi usare il telefono mentre scarica e installa, perché il lavoro avviene sull’altra metà. E se la nuova versione non parte, il bootloader torna da solo alla vecchia: il telefono resta acceso invece di trasformarsi in un fermacarte.

Google ha introdotto il meccanismo con Android 7.0 sui Pixel del 2016. Prima si aggiornava dalla recovery, con il telefono fermo e il rischio concreto di un avvio fallito senza ritorno.

Come funzionano gli slot A e B negli aggiornamenti A/B

Le due copie si chiamano slot e nella pratica vengono indicate come slot A e slot B. A ogni slot il bootloader associa due attributi. Il primo è bootable: quella copia contiene un sistema avviabile. Il secondo è successful: quel sistema si è già avviato almeno una volta senza errori.

Il ciclo di un aggiornamento, in ordine:

1. Il client OTA controlla il server e scarica il pacchetto.
2. Il demone update_engine scrive i blocchi nella partizione dello slot inattivo mentre il telefono è in uso.
3. Al termine il bootloader riceve l’ordine di avviare lo slot nuovo al riavvio successivo.
4. Se il nuovo sistema parte, lo slot viene marcato successful. Se non parte dopo alcuni tentativi, il bootloader torna allo slot precedente e lo rende di nuovo attivo.

Dall’Android 8.0 i pacchetti possono arrivare in streaming: i blocchi vengono scritti man mano che il download procede, senza doverli prima salvare per intero nella memoria interna. Per questo un aggiornamento da 2 GB non richiede 2 GB liberi. Su un telefono con slot di sistema separati e senza streaming, invece, serviva spazio per il pacchetto più lo spazio per l’installazione.

Il caso pratico: hai un Pixel con lo slot A attivo. Android scarica l’OTA e scrive tutto sullo slot B, che nel frattempo è inutilizzato. Tu rispondi alle email, guardi un video e non ti accorgi di nulla. Poi arriva la notifica di riavvio. Solo quel riavvio costa il tempo di un avvio normale.

Un dettaglio che sfugge: senza A/B un telefono di tre anni come il Galaxy A34 che riceve One UI 9 con Android 17 dovrebbe passare dalla recovery per ogni major update. Con due slot la distribuzione si fa in background, ed è una delle ragioni per cui il supporto software lungo è diventato sostenibile anche sul medio gamma.

Perché il telefono si riavvia due volte durante l’aggiornamento?

Il primo riavvio è il passaggio allo slot nuovo. Il secondo dipende dal post-install: firmware del modem, bootloader, vbmeta e altre parti che non si possono aggiornare mentre il sistema gira vengono scritte dopo, con una procedura che richiede un riavvio ulteriore.

C’è poi il primo avvio vero e proprio, lento per un motivo diverso. Android ricompila e ottimizza le app per la nuova versione: su Samsung lo vedi come “Ottimizzazione delle app”, su Pixel come finalizzazione dell’aggiornamento. Può durare pochi minuti o un quarto d’ora se hai centinaia di applicazioni installate.

Regola pratica: se lo schermo mostra un logo o una barra che si muove, il telefono sta lavorando. Se resta nero e fermo per più di venti minuti, allora c’è un problema e conviene cercare il supporto del produttore.

Cosa cambia con il Virtual A/B introdotto in Android 10

Con Android 10 Google ha sostituito l’A/B classico con il Virtual A/B. La differenza sostanziale è questa: non esiste più una seconda copia fisica delle partizioni dinamiche, cioè quelle che contengono sistema e vendor e che si ridimensionano.

Il pacchetto viene scritto in uno snapshot, un’immagine temporanea in formato copy-on-write (COW). In parole semplici: si salvano solo i blocchi che cambiano, non l’intera partizione. Dopo il riavvio e il boot riuscito, lo snapshot viene fuso nella partizione di base mentre il telefono lavora, con il demone snapuserd che gestisce le letture.

I numeri utili: solo le partizioni usate dal bootloader vengono duplicate davvero. Con la compressione introdotta in Android 12 lo snapshot di un OTA completo pesa circa il 45% in meno, quello di un OTA incrementale circa il 55% in meno. Da Android 13 la compressione XOR è attiva per impostazione predefinita sui dispositivi che arrivano con quella versione.

Dal punto di vista commerciale il Virtual A/B è un requisito GMS per i dispositivi lanciati con Android 11 o successivi. Tradotto: se il telefono è recente e ha Google Play, quasi certamente lo usa. I dispositivi non A/B sono stati dichiarati deprecati da Android 15, quindi la strada è tracciata.

Il prezzo da pagare è lo spazio nella partizione dati. Lo snapshot vive lì, quindi un telefono con 500 MB liberi può rifiutare l’aggiornamento. È il caso classico del telefono pieno di foto che “non trova spazio per aggiornarsi”. La causa non è la partizione di sistema ma la memoria che usi ogni giorno.

Quando gli aggiornamenti A/B non ci sono o non funzionano

Non tutti i telefoni hanno due slot. Modelli economici e diversi dispositivi più vecchi usano una partizione singola: l’aggiornamento si applica dalla recovery, con il telefono fermo e una schermata di installazione che nessuno può evitare. Se il tuo telefono mostra quella schermata, il motivo è questo.

Sui dispositivi A-only il fallback non esiste. Un’interruzione a metà scrittura può richiedere un ripristino via PC, con Odin su Samsung o con fastboot su Xiaomi e Pixel. Per questo i produttori tendono a riservare l’A/B ai modelli che vendono di più, dove un reso in garanzia costa caro.

Le custom ROM cambiano il quadro. Una build come LineageOS si installa via recovery o sideload e non usa il client OTA del produttore, quindi il ciclo descritto sopra non si applica. Su alcuni dispositivi la struttura a slot resta, ma la gestione è della ROM e non di Google.

Un altro caso è il rollback. Una volta che il nuovo slot ha completato il boot e viene marcato successful, non si torna indietro con un comando: la protezione anti-rollback del bootloader blocca le versioni precedenti firmate con chiavi vecchie. Se l’aggiornamento è partito e non ti soddisfa, le strade reali sono altre e le abbiamo raccolte in annullare un aggiornamento Android.

Come verificare lo slot attivo e lo stato degli aggiornamenti A/B

Il modo diretto richiede ADB, cioè il debug USB attivo e un computer collegato. Da terminale bastano tre comandi:

• adb shell getprop ro.boot.slot_suffix restituisce _a oppure _b: è lo slot da cui è partito il sistema.
• adb shell getprop ro.build.ab_update vale true se il dispositivo usa aggiornamenti A/B.
• adb shell getprop ro.virtual_ab.enabled e ro.virtual_ab.compression.enabled dicono se è attivo il Virtual A/B e se lo snapshot è compresso.

Senza PC il controllo è indiretto. In fastboot, cioè la modalità bootloader, la riga current-slot mostra lo slot attivo. Su Samsung il fastboot non c’è: si passa dalla download mode e da Odin, oppure ci si limita alla versione software nelle impostazioni.

C’è poi la verifica che conta davvero per chi usa il telefono. Dopo l’aggiornamento apri Impostazioni > Informazioni sul telefono > Aggiornamento software e controlla la versione di build. Se il numero è cambiato e il livello di patch di sicurezza è aggiornato, il passaggio ha funzionato. Il livello patch Android è il dato più onesto per capire se le correzioni sono arrivate sul dispositivo.

Ultimo dettaglio: dopo un aggiornamento Virtual A/B lo spazio libero può calare ancora per qualche ora. È la fusione dello snapshot in corso, non un bug. Se ti serve spazio subito, le cause ricorrenti sono in perché le app occupano sempre più spazio su Android.

Domande frequenti sugli aggiornamenti A/B

Gli aggiornamenti A/B occupano il doppio dello spazio?

Con l’A/B classico sì, perché le partizioni di sistema esistono in due copie fisiche. Con il Virtual A/B no: viene duplicato solo ciò che serve al bootloader, mentre il resto passa da uno snapshot nel quale finiscono unicamente i blocchi modificati. Con la compressione lo snapshot di un OTA completo è circa il 45% più piccolo del pacchetto non compresso.

Posso tornare alla versione precedente dopo un aggiornamento A/B?

Solo se il nuovo sistema non riesce ad avviarsi. In quel caso il bootloader torna allo slot vecchio in automatico. Se invece il boot è riuscito e lo slot è marcato successful, la protezione anti-rollback impedisce di installare una build precedente firmata con chiavi vecchie.

Perché il mio telefono non ha gli aggiornamenti A/B?

Quasi sempre per una scelta di costo. Servono spazio doppio per le partizioni di sistema o, nelle versioni Virtual, un’implementazione più complessa nel firmware. Sui modelli economici il produttore preferisce la partizione singola e l’aggiornamento dalla recovery.

Cosa succede se il telefono si spegne durante l’aggiornamento?

Dipende dalla fase. Se si spegne mentre update_engine scrive lo slot inattivo, lo slot attivo è intatto e al riavvio riparte la vecchia versione, poi il download si ripete. Se si spegne durante la fusione dello snapshot, il sistema riprende la fusione al boot successivo, perché lo stato è persistente su disco.

Gli aggiornamenti A/B funzionano con root o bootloader sbloccato?

Spesso no. Un’immagine di boot modificata o un vbmeta alterato fanno fallire la verifica e l’OTA viene rifiutato, oppure si installa e il dispositivo non supera i controlli di integrità. Per riprendere gli aggiornamenti bisogna ripristinare boot e vbmeta originali, perdendo il root nel passaggio.

Perché il primo avvio dopo l’aggiornamento è così lento?

Perché Android deve ricompilare le app per la nuova versione del runtime e rigenerare le cache. Il lavoro viene fatto una volta sola, ma su un telefono con molte app può richiedere parecchi minuti. Il secondo riavvio del post-install è un’altra cosa e riguarda il firmware.

Come capire se l’aggiornamento A/B è andato a buon fine?

Controlla la versione di build e il livello di patch in Impostazioni > Informazioni sul telefono > Aggiornamento software. Se i numeri sono cambiati e non compare nessun avviso di rollback, il passaggio è completo. Con ADB, ro.boot.slot_suffix mostrerà lo slot opposto a quello usato prima dell’aggiornamento.