OTA fallito su Android con root: diagnosi prima del reflash
Un OTA fallito su un telefono con root di solito è il sistema di aggiornamento che fa il suo lavoro. Scopri a cosa ha obiettato prima di ricorrere a un flash completo del firmware.

Indice
- Perché l’aggiornamento è stato rifiutato
- Prima di tutto: che schema di partizioni usa il tuo dispositivo?
- Le cause possibili
- L’ordine della diagnosi
- Leggi l’errore
- Individua cosa è modificato
- Ripristina prima di aggiornare, non dopo
- Tieni pronte le immagini stock corrette
- Tornare a uno stato di avvio funzionante
- Rischio per i dati, detto chiaramente
- Perché non esiste una sequenza universale
- Domande frequenti
Un OTA rifiutato su un telefono con root di solito è il sistema di aggiornamento che funziona correttamente. Ha controllato le partizioni che stava per aggiornare, le ha trovate modificate e si è fermato. È un esito di verifica, non un danno, e la soluzione è capire a quale partizione si è opposto, invece di flashare sopra un pacchetto firmware completo.
Perché l’aggiornamento è stato rifiutato
Il processo di aggiornamento di Android verifica lo stato attuale delle partizioni che intende sostituire prima di scrivere qualsiasi cosa. Se una partizione non corrisponde a ciò che il pacchetto di aggiornamento si aspetta, l’aggiornamento si ferma, invece di produrre un sistema aggiornato a metà e imprevedibile.
Il root modifica la catena di avvio. È tutto qui il meccanismo. Quindi un dispositivo con root presenta esattamente la discrepanza che quel controllo è progettato per intercettare.
Vale la pena tenerlo a mente, perché cambia il modo di vedere il problema. Il dispositivo non è rotto. A livello hardware non è andato storto nulla. Qualcosa è modificato, l’updater se n’è accorto e ha rifiutato. Il tuo compito è capire cosa.
Tieni presente anche che le partizioni possono essere modificate senza che la colpa sia del root. Una custom recovery a cui è stato permesso di modificare il sistema, un’app con privilegi di root che ha cambiato un file di sistema o un residuo di una modifica precedente producono lo stesso rifiuto anche con il root rimosso da tempo.
Prima di tutto: che schema di partizioni usa il tuo dispositivo?
Da questo dipende quasi tutto ciò che puoi fare, ed è la prima domanda a cui rispondere.
I dispositivi A/B tengono due copie delle partizioni interessate. Gli aggiornamenti si installano sul set inattivo mentre continui a usare quello attivo, e il dispositivo passa all’altro al riavvio. È il modello di aggiornamento senza interruzioni.
I dispositivi non A/B hanno una sola copia. L’aggiornamento si applica alle partizioni che stai usando, in genere tramite la recovery.
Non esiste una scorciatoia affidabile per capire quale hai dal nome commerciale. Controlla il layout delle partizioni sul dispositivo stesso, oppure la documentazione del produttore per il tuo modello esatto. Sbagliare ti porta su una procedura che non si applica.
La differenza pratica:
| A/B | Non A/B | |
|---|---|---|
| Dove finisce l’aggiornamento | Slot inattivo | Le partizioni in uso |
| Piano B se fallisce | L’altro slot è ancora intatto | Nessuna seconda copia |
| Mantenere il root tra un aggiornamento e l’altro | Possibile, con la procedura documentata | Di solito il root va riapplicato dopo |
| Profilo di rischio di un aggiornamento fallito | Più basso, lo slot funzionante si salva | Più alto |
Le cause possibili
Sono ipotesi. Quale vale per te dipende dal dispositivo e da ciò che hai installato.
1. Una boot image modificata. Il caso più diretto. Il root ha patchato la catena di avvio, l’updater l’ha controllata e non corrispondeva.
2. Le immagini stock non sono mai state salvate. I framework di root possono ripristinare le immagini originali prima di un aggiornamento, ma solo se esiste un backup. Se il dispositivo è stato rootato flashando direttamente un’immagine già patchata, invece che con il flusso di installazione del framework, potrebbe non esserci nulla da cui ripristinare, e il passaggio di ripristino fallirà.
3. Una partizione di sistema modificata. Una custom recovery a cui è stato permesso di modificare il sistema, o un’app root che vi ha scritto, lascia una modifica che l’updater intercetta. Questa causa resta anche dopo la rimozione del root e confonde parecchio, perché si toglie il root, si riprova e si ottiene lo stesso rifiuto.
4. Moduli che interferiscono. I moduli che alterano il comportamento del sistema o i suoi file possono influire sulla verifica o sull’avvio dopo l’aggiornamento.
5. Stato degli slot. Sui dispositivi A/B contano sia lo slot attivo al momento dell’aggiornamento sia lo slot a cui era destinato l’aggiornamento. Conta anche se un aggiornamento precedente ha lasciato gli slot in uno stato inatteso.
6. Stato della recovery. Una custom recovery al posto di quella stock cambia ciò che succede quando l’aggiornamento prova a usarla.
L’ordine della diagnosi
Segui questi passi prima di toccare un pacchetto firmware.
Leggi l’errore
Annota l’errore esatto, il punto del processo in cui è fallito e se poi il dispositivo si è riavviato in recovery. Un aggiornamento che fallisce durante il download è un problema diverso da uno che fallisce durante la verifica, che a sua volta è diverso da uno che si installa e poi non si avvia.
Se ora il dispositivo non si avvia, invece di limitarsi a non aggiornarsi, fermati qui e passa a cosa significa ogni sintomo di avvio, perché sei in una situazione diversa.
Individua cosa è modificato
Prima di riportare qualcosa allo stock, devi sapere cosa non lo è. Boot, e sui dispositivi più recenti forse un’immagine separata che contiene il ramdisk, è il sospetto ovvio. System è quello che molti dimenticano, e subito dopo viene recovery.
Se le modifiche non le hai installate tu, o se il dispositivo è di seconda mano, parti dal presupposto di non sapere e considera aperta ogni possibile causa.
Ripristina prima di aggiornare, non dopo
La documentazione di Magisk descrive direttamente il flusso previsto: ripristina le immagini stock dal backup fatto da Magisk durante l’installazione, così la verifica che precede l’aggiornamento passa, e in particolare non riavviare dopo il ripristino, perché a quel punto il riavvio completa una disinstallazione. Il dispositivo poi accetta l’aggiornamento normalmente e il root si riapplica dopo, con la procedura documentata.
Leggi la documentazione attuale della soluzione di root che hai installato davvero, e leggila per lo schema di partizioni del tuo dispositivo. Questo flusso è cambiato nelle varie versioni e le differenze tra la gestione A/B e non A/B sono significative. Le istruzioni di un vecchio thread di un forum possono descrivere un meccanismo che non esiste più.
La documentazione di Magisk precisa anche che sui dispositivi non A/B non esiste un approccio senza interruzioni e che il root andrà riapplicato a mano con un computer dopo l’aggiornamento. Meglio saperlo prima di iniziare che scoprirlo a metà strada.
Tieni pronte le immagini stock corrette
Se manca il backup del framework, ti servono le immagini originali per il tuo modello esatto e per la tua build attuale esatta, dalla distribuzione del produttore. Non una versione simile. Non un’altra regione. È sull’abbinamento della build che si sbaglia più spesso, e il risultato è un dispositivo che si flasha senza errori e non si avvia.
Tornare a uno stato di avvio funzionante
Se il dispositivo si avvia ancora, hai tempo e opzioni. Sfruttali.
Se dopo il tentativo il dispositivo non si avvia più, la priorità diventa ripristinare uno stato avviabile, e su un dispositivo A/B la prima cosa da guardare è l’altro slot. Se contenga qualcosa di utile dipende dalla cronologia degli aggiornamenti, ma controllare non costa nulla ed è un’operazione non distruttiva.
Ripristinare la boot image originale corretta scrive solo sulla partizione boot. Non tocca i dati dell’utente. È l’operazione che vuoi. Un flash completo del firmware è un’operazione diversa con conseguenze diverse, descritte più avanti.
Rischio per i dati, detto chiaramente
Niente della diagnosi qui sopra tocca i dati dell’utente. Queste operazioni invece sì:
| Azione | Distruttiva? |
|---|---|
| Ripristino delle boot image stock | No, solo la partizione boot |
| Applicazione di un OTA ufficiale | No per i dati dell’utente |
| Sideload di un pacchetto ufficiale firmato | No per i dati dell’utente |
| Cambio dello slot attivo | No, di per sé |
| Ripristino di fabbrica da recovery o Settings | Sì, irreversibile |
| Format data | Sì, irreversibile |
Flash del firmware con opzione di wipe o flag -w | Sì, irreversibile |
| Blocco o sblocco del bootloader | Sì, lo sblocco avvia un wipe |
La trappola è lo script di flash del produttore che include un passaggio di wipe per impostazione predefinita. C’è chi lo esegue per riparare un aggiornamento fallito e perde tutto quello che c’è sul dispositivo. Apri lo script e leggilo. Su un dispositivo con crittografia basata su file, un wipe elimina anche il materiale delle chiavi insieme ai dati, quindi dopo non c’è modo di recuperare nulla. La nostra guida al bootloop senza perdita di dati spiega perché questo cambia la sequenza da seguire.
Se il dispositivo contiene dati di cui non hai un backup, fallo adesso, finché si avvia. È questo il momento, e non tornerà.
Perché non esiste una sequenza universale
Ogni produttore implementa gli aggiornamenti in modo diverso. Il modello di flash di Samsung non è quello di Google. Quello di Xiaomi non è quello di OnePlus. All’interno di uno stesso marchio i dispositivi cambiano per generazione, regione e variante dell’operatore.
Per questo l’articolo ti dà le categorie e l’ordine in cui ragionare, non un elenco di comandi. Un elenco di comandi sarebbe sbagliato per alcuni lettori, con il rischio di far perdere loro i dati, e non c’è modo di scriverne uno sicuro per tutti i dispositivi.
Cerca la procedura specifica per il tuo modello e la tua build esatti, presso il produttore o in una fonte mantenuta e dedicata al dispositivo. La nostra lista dei dispositivi rootabili indica dove le differenze tra marchi sono più marcate.
Domande frequenti
Posso semplicemente saltare l’aggiornamento? Puoi, e per una singola versione è una scelta ragionevole. Col tempo però accumuli patch di sicurezza perse e il divario tra la tua build e il firmware attuale si allarga, rendendo l’aggiornamento finale più difficile, non più facile.
Togliere il root risolve il problema? A volte sì e a volte no, ed è questa la parte che confonde. Se è stata modificata solo la catena di avvio, ripristinarla elimina la discrepanza. Se sono state modificate anche la partizione di sistema o la recovery, togliere il root lascia quelle modifiche al loro posto e l’aggiornamento viene comunque rifiutato.
Il telefono si è aggiornato ma ha perso il root. È un fallimento? No, è uno degli esiti documentati, in particolare sui dispositivi non A/B. L’aggiornamento è riuscito e la modifica è stata sostituita. Rifai il root dopo, con la procedura normale, usando le immagini della nuova build.
L’aggiornamento si è installato e ora non si avvia. È un problema diverso, e più urgente. Vai a cosa significa ogni sintomo di avvio e, se il dispositivo finisce in recovery, a cosa controllare quando si riavvia sempre lì. Non fare il reset.
Dovrei usare un’utility di riparazione del produttore? Questi strumenti in genere scaricano il firmware stock e lo flashano, ed è legittimo. Quello che conta è se quel flash conserva i dati dell’utente sul tuo dispositivo specifico, e dipende dal firmware e dalla modalità, non dall’interfaccia dello strumento. Controlla prima di eseguirlo.
Vale la pena restare con il root se gli aggiornamenti continuano a fallire? È una valutazione su ciò che il root ti dà. La nostra analisi onesta dei rischi del root spiega il compromesso, compreso l’attrito con gli aggiornamenti, che è un costo reale e continuo, non una tantum.
Letture correlate: Flash di Magisk non riuscito · Risolvere un bootloop senza perdere i dati · Android si riavvia sempre in recovery · Errori FAIL di Odin su Samsung · Moduli Magisk essenziali
Fonti: documentazione ufficiale di Magisk sugli aggiornamenti OTA. Documentazione di Android Open Source Project sugli aggiornamenti di sistema A/B.
Ultima verifica: 19 agosto 2026. I meccanismi di aggiornamento, gli schemi di partizioni e le procedure di flash dei produttori variano per modello, regione e build. Verifica con la documentazione ufficiale del tuo dispositivo esatto.