OTA-Update auf gerootetem Android fehlgeschlagen: vor dem erneuten Flashen diagnostizieren
Scheitert ein OTA auf einem gerooteten Handy, macht die Update-Engine meist nur ihren Job. Finde heraus, woran sie sich gestört hat, bevor du eine komplette Firmware flashst.

Inhaltsverzeichnis
- Warum das Update abgelehnt wurde
- Zuerst: Welches Partitionsschema nutzt dein Gerät?
- Die möglichen Ursachen
- Die Reihenfolge der Diagnose
- Den Fehler lesen
- Klären, was verändert wurde
- Vor dem Update wiederherstellen, nicht danach
- Die passenden Stock-Images bereithalten
- Zurück zu einem sauberen Boot-Zustand
- Das Datenrisiko, klar benannt
- Warum es keine universelle Abfolge gibt
- Häufige Fragen
Ein abgelehntes OTA auf einem gerooteten Handy bedeutet meist, dass die Update-Engine korrekt arbeitet. Sie hat die Partitionen geprüft, die sie aktualisieren wollte, Änderungen gefunden und gestoppt. Das ist ein Prüfergebnis und kein Schaden. Finde deshalb heraus, an welcher Partition sie sich gestört hat, statt ein komplettes Firmware-Paket darüberzuflashen.
Warum das Update abgelehnt wurde
Der Android-Updateprozess prüft den aktuellen Zustand der Partitionen, die er ersetzen will, bevor er etwas schreibt. Passt eine Partition nicht zu dem, was das Update-Paket erwartet, bricht das Update ab, statt ein unberechenbares, halb aktualisiertes System zu erzeugen.
Root verändert die Boot-Kette. Das ist der ganze Mechanismus. Ein gerootetes Gerät zeigt also genau die Abweichung, die diese Prüfung finden soll.
Das ist hilfreich zu verstehen, weil es das Problem neu einordnet. Das Gerät ist nicht kaputt. Auf Hardwareebene ist nichts schiefgelaufen. Etwas ist verändert, der Updater hat es bemerkt und abgelehnt. Deine Aufgabe ist, herauszufinden, was.
Beachte auch: Partitionen können verändert sein, ohne dass Root schuld ist. Eine Custom Recovery, die das System ändern durfte, eine Root-App, die eine Systemdatei geändert hat, oder ein Überbleibsel einer früheren Modifikation führen zur gleichen Ablehnung, selbst wenn Root längst entfernt ist.
Zuerst: Welches Partitionsschema nutzt dein Gerät?
Davon hängen fast alle deine Optionen ab, deshalb ist es die erste Frage.
A/B-Geräte haben zwei Kopien der relevanten Partitionen. Updates landen im inaktiven Satz, während du den aktiven weiter nutzt, und beim Neustart schaltet das Gerät um. Das ist das nahtlose Update-Modell.
Nicht-A/B-Geräte haben nur eine Kopie. Das Update wird auf die laufenden Partitionen angewendet, meist über die Recovery.
Am Marketingnamen lässt sich nicht zuverlässig erkennen, was du hast. Prüfe das Partitionslayout direkt auf dem Gerät oder die Herstellerdokumentation für dein genaues Modell. Wer das falsch einschätzt, folgt einer Anleitung, die nicht passt.
Der praktische Unterschied:
| A/B | Nicht-A/B | |
|---|---|---|
| Wohin das Update geht | Inaktiver Slot | Die genutzten Partitionen |
| Rückfall bei Fehler | Der andere Slot ist intakt | Keine zweite Kopie |
| Root über Updates hinweg erhalten | Möglich, über den dokumentierten Ablauf | Root muss meist danach neu eingerichtet werden |
| Risiko bei fehlgeschlagenem Update | Niedriger, der laufende Slot bleibt erhalten | Höher |
Die möglichen Ursachen
Das sind mögliche Ursachen. Welche zutrifft, hängt von deinem Gerät und deinen Änderungen ab.
1. Ein verändertes Boot-Image. Der direkteste Fall. Root hat die Boot-Kette gepatcht, der Updater hat sie geprüft, sie passte nicht.
2. Es gab nie ein Backup der Stock-Images. Root-Frameworks können die Original-Images vor einem Update wiederherstellen, aber nur, wenn ein Backup existiert. Wurde das Gerät gerootet, indem direkt ein vorgepatchtes Image geflasht wurde statt über den eigenen Installationsablauf des Frameworks, gibt es womöglich nichts zum Wiederherstellen, und dieser Schritt schlägt fehl.
3. Eine veränderte System-Partition. Eine Custom Recovery, die das System ändern durfte, oder eine Root-App, die darauf geschrieben hat, hinterlässt eine Änderung, die der Updater bemerkt. Sie bleibt auch nach dem Entfernen von Root bestehen und verwirrt viele: Sie entfernen Root, versuchen es erneut und bekommen dieselbe Ablehnung.
4. Störende Module. Module, die das Systemverhalten oder Systemdateien verändern, können die Prüfung oder den Start nach dem Update beeinflussen.
5. Slot-Zustand. Bei A/B-Geräten zählt, welcher Slot beim Update aktiv war und welchen das Update als Ziel hatte. Ebenso, ob ein früheres Update die Slots in einem unerwarteten Zustand hinterlassen hat.
6. Recovery-Zustand. Eine Custom Recovery statt der Stock-Recovery ändert, was passiert, wenn das Update sie nutzen will.
Die Reihenfolge der Diagnose
Geh diese Schritte durch, bevor du ein Firmware-Paket anfasst.
Den Fehler lesen
Notiere den genauen Fehler, die Stelle im Ablauf, an der er auftrat, und ob das Gerät danach in die Recovery gestartet ist. Ein Update, das beim Download scheitert, ist ein anderes Problem als eines, das bei der Prüfung scheitert, und wieder ein anderes als eines, das installiert wird und dann nicht startet.
Startet das Gerät nun nicht mehr, statt nur das Update zu verweigern, hör hier auf und lies was die einzelnen Boot-Symptome bedeuten, denn du bist in einer anderen Lage.
Klären, was verändert wurde
Bevor du etwas im Originalzustand wiederherstellen kannst, musst du wissen, was nicht Stock ist. Boot, auf neueren Geräten eventuell zusätzlich ein separates Image mit der Ramdisk, ist der naheliegende Kandidat. Das System vergessen viele. Die Recovery vergessen sie als Zweites.
Hast du die Änderungen nicht selbst vorgenommen oder das Gerät übernommen, geh davon aus, dass du es nicht weißt, und behandle jeden Kandidaten als offen.
Vor dem Update wiederherstellen, nicht danach
Die Magisk-Dokumentation beschreibt den vorgesehenen Ablauf direkt: Stelle die Stock-Images aus dem Backup wieder her, das Magisk bei der Installation angelegt hat, damit die Prüfung vor dem Update bestanden wird, und starte danach ausdrücklich nicht neu, denn ein Neustart an dieser Stelle schließt eine Deinstallation ab. Das Gerät nimmt das Update dann normal an, und Root wird anschließend über den dokumentierten Weg neu eingerichtet.
Lies die aktuelle Dokumentation der Root-Lösung, die du tatsächlich installiert hast, und zwar für das Partitionsschema deines Geräts. Dieser Ablauf hat sich über die Versionen geändert, und die Unterschiede zwischen A/B und Nicht-A/B sind erheblich. Eine Anleitung aus einem alten Forenthread beschreibt womöglich einen Mechanismus, den es nicht mehr gibt.
Die Magisk-Dokumentation sagt auch offen, dass es bei Nicht-A/B-Geräten keinen nahtlosen Weg gibt und Root danach manuell mit einem Computer neu eingerichtet werden muss. Das solltest du vorher wissen und nicht mittendrin merken.
Die passenden Stock-Images bereithalten
Fehlt das Backup des Frameworks, brauchst du die Original-Images für dein genaues Modell und deinen genauen aktuellen Build, aus der Distribution des Herstellers. Keine ähnliche Version. Keine andere Region. An der Build-Zuordnung scheitert es am häufigsten, und das Ergebnis ist ein Gerät, das sauber geflasht wird und nicht startet.
Zurück zu einem sauberen Boot-Zustand
Startet das Gerät noch, hast du Zeit und Optionen. Nutze sie.
Startet das Gerät nach dem Versuch nicht mehr, ändert sich die Priorität: Es geht darum, wieder einen bootfähigen Zustand herzustellen. Bei einem A/B-Gerät schaust du zuerst auf den anderen Slot. Ob dort etwas Brauchbares liegt, hängt von deiner Update-Historie ab, aber der Blick kostet nichts und zerstört nichts.
Das Zurückspielen des richtigen Original-Boot-Images schreibt nur in die Boot-Partition. Nutzerdaten bleiben unberührt. Das ist die Operation, die du willst. Ein vollständiger Firmware-Flash ist etwas anderes mit anderen Folgen, siehe unten.
Das Datenrisiko, klar benannt
Nichts in der Diagnose oben berührt Nutzerdaten. Diese Dinge tun es:
| Aktion | Zerstörerisch? |
|---|---|
| Stock-Boot-Images wiederherstellen | Nein, nur die Boot-Partition |
| Ein offizielles OTA anwenden | Nein, nicht für Nutzerdaten |
| Ein offizielles signiertes Paket per Sideload einspielen | Nein, nicht für Nutzerdaten |
| Den aktiven Slot wechseln | An sich nein |
| Werksreset per Recovery oder Einstellungen | Ja, nicht umkehrbar |
| Format data | Ja, nicht umkehrbar |
Ein Firmware-Flash mit Wipe-Option oder -w-Flag | Ja, nicht umkehrbar |
| Bootloader sperren oder entsperren | Ja, das Entsperren löst einen Wipe aus |
Die Falle ist das Flash-Skript des Herstellers, das standardmäßig einen Wipe-Schritt enthält. Wer es zur Reparatur eines fehlgeschlagenen Updates ausführt, verliert alles auf dem Gerät. Öffne das Skript und lies es. Bei Geräten mit dateibasierter Verschlüsselung entfernt ein Wipe mit den Daten auch das Schlüsselmaterial, danach gibt es keine Wiederherstellung. Unser Guide zum Bootloop ohne Datenverlust erklärt, warum sich dadurch die richtige Reihenfolge ändert.
Liegen auf dem Gerät Daten ohne Backup, sichere sie jetzt, solange es noch startet. Das ist der Moment, und er kommt nicht wieder.
Warum es keine universelle Abfolge gibt
Jeder Hersteller setzt Updates anders um. Samsungs Flash-Modell ist nicht das von Google. Das von Xiaomi ist nicht das von OnePlus. Selbst innerhalb einer Marke unterscheiden sich Geräte nach Generation, Region und Netzbetreiber-Variante.
Dieser Artikel liefert dir deshalb die Kategorien und die Denkreihenfolge, keine Befehlsliste. Eine Befehlsliste wäre für manche Leser falsch, und zwar so, dass sie ihre Daten verlieren. Eine, die über alle Geräte sicher ist, lässt sich nicht schreiben.
Such dir das passende Verfahren für dein genaues Modell und deinen Build, beim Hersteller oder in einer gepflegten gerätespezifischen Quelle. Unsere Liste rootbarer Geräte zeigt, wo die Unterschiede zwischen den Marken am größten sind.
Häufige Fragen
Kann ich das Update einfach überspringen? Ja, und für eine Version ist das vertretbar. Mit der Zeit häufen sich verpasste Sicherheitspatches, und der Abstand zwischen deinem Build und der aktuellen Firmware wächst. Das macht das spätere Update schwerer, nicht leichter.
Hilft es, Root zu entfernen? Manchmal, aber nicht immer, und das verwirrt. Wurde nur die Boot-Kette verändert, behebt ihre Wiederherstellung die Abweichung. Wurden auch System-Partition oder Recovery verändert, bleiben diese Änderungen nach dem Entfernen von Root bestehen, und das Update wird weiter abgelehnt.
Mein Handy wurde aktualisiert, hat aber Root verloren. Ist das ein Fehler? Nein, das ist eines der dokumentierten Ergebnisse, vor allem bei Nicht-A/B-Geräten. Das Update war erfolgreich, und die Modifikation wurde ersetzt. Roote danach auf dem normalen Weg neu, mit den Images des neuen Builds.
Das Update wurde installiert, und jetzt startet das Gerät nicht. Das ist ein anderes und dringenderes Problem. Lies was die einzelnen Boot-Symptome bedeuten und, falls das Gerät in der Recovery landet, was du prüfen solltest, wenn es immer wieder dort startet. Setz nicht zurück.
Soll ich ein Reparaturprogramm des Herstellers nutzen? Diese Tools laden meist die Stock-Firmware herunter und flashen sie, das ist legitim. Entscheidend ist, ob dieser Flash auf deinem Gerät die Nutzerdaten erhält. Das bestimmen Firmware und Modus, nicht die Oberfläche des Tools. Prüfe das vor dem Start.
Lohnt sich Root, wenn Updates ständig scheitern? Das ist eine Abwägung dessen, was dir Root bringt. Unser ehrlicher Blick auf die Risiken von Root erklärt, was Root kostet, auch die Update-Hürden, die eine dauerhafte und keine einmalige Last sind.
Weiterlesen: Magisk-Flash fehlgeschlagen · Bootloop ohne Datenverlust beheben · Android startet immer wieder in die Recovery · Samsung-Odin-FAIL-Fehler · Wichtige Magisk-Module
Quellen: Offizielle Magisk-Dokumentation zum OTA-Upgrade. Dokumentation des Android Open Source Project zu A/B-Systemupdates.
Zuletzt geprüft: 19. August 2026. Update-Mechanismen, Partitionsschemata und Flash-Verfahren der Hersteller unterscheiden sich je nach Modell, Region und Build. Prüfe die Angaben in der offiziellen Dokumentation deines Geräts.