OTA-Update trotz Root: Ab Android 5.0 nicht mehr möglich

Du hast dein Handy mit Android 5 gerootet und möchtest nun ein OTA-Update einspielen, bekommst aber immer eine Fehlermeldung? Oder du bist neu bei Android 5 und möchtest wissen, ob du nach dem Rooten noch automatische Updates bekommst? Dieser Artikel gibt Antwort zu diesen zwei Fragen und erklärt dabei, warum das OTA-Update unter Android 5 bei jeglicher Modifikation scheitert, und welche Workarounds es für das Problem gibt.

Die wenigsten Nutzer verstehen den Zusammenhang zwischen Root, einem Custom-Bootloader und einer Custom-ROM wirklich, geschweige denn wie das alles mit den Updates vom Hersteller zusammenhängt. Seit Android 5.0 gibt es hier grundlegende Änderungen am System, wie die neuen Firmware-Dateien ausgeliefert und installiert werden. Dabei soll aber auch nicht verschwiegen werden, dass du je nach Handy komplett im Regen stehst, wenn du dein Gerät bereits gerootet hast und es keine Recovery-Firmware vom Hersteller gibt.

Bootloader, Root, Custom-ROM, Custom-Recovery

Um die Neuerungen zu verstehen, sollte dir zunächst klar sein, was die obigen Begriffe bedeuten: Mit Bootloader (zum Beispiel bootloader-flounder-3.44.1.0123.img oder motoboot.img) bei Motorola ist das Programm gemeint, das für den Start von Android verantwortlich ist. Dabei handelt es sich um ein Stück proprietären Code, keine freie Software. Jeder Hersteller benutzt einen anderen Bootloader, Google selbst setzt ebenfalls auf einen eigenen Bootloader, der bei den meisten — aber nicht bei allen — Nexus-Geräten zum Einsatz kommt. Die Bootloader-Datei ist üblicherweise nur zwei bis drei MByte groß.

Für jede tiefergreifende Änderung, die du am System vornehmen möchtest, musst du üblicherweise den Bootloader entsperren. Das ist je nach Hersteller legal und absolut simpel oder nur über Umwege bzw. mit der Brechstange möglich. Hinsichtlich des Entsperrens des Bootloaders hat sich mit Android 5.x nichts geändert. Jeder Hersteller kocht sein eigenes Süppchen und deshalb hängt es vom Hersteller ab, ob das Entsperren Konsequenzen mit sich bringt und welche das sind. Üblicherweise musst du auf die freiwillige Herstellergarantie verzichten, wenn du den Bootloader entsperren willst. Die bootloader.img-Datei ist nicht zu verwechseln mit der Datei boot.img, die üblicherweise den Kernel und die Ramdisk enthält und zwischen 6 und 10 MByte groß ist.

Der Bootloader befindet sich auf einem separaten Bereich des Flash-Speichers, getrennt von den System-Daten oder Nutzerdaten (für Dummies: nicht auf dem Laufwerk „C“, sondern auf dem Laufwerk „A“). Ohne (funktionierenden) Bootloader kannst du das Android-System nicht starten. Der Bootloader befindet sich normalerweise auf einem eMMC- oder MTD-Block (Memory Technology Device) und ist wenige MByte groß.

Der entsperrte Bootloader ist die Tür zu einem Custom-Recovery. Dabei handelt es sich um eine Art Bootmenü mit zahlreichen Funktionen zur Maintenance. In dieses Bootmenü gelangst du üblicherweise, wenn du beim Einschalten des Smartphones die Leiser-Taste gedrückt hältsts. Auch das Bootmenü (recovery.img) befindet sich auf einem separaten Bereich des Flash-Speichers, üblicherweise auf einem rohen eMMC-Block.

Ein Custom-Recovery ist üblicherweise der erste, zwingende Schritt, um an Root-Rechte zu gelangen (abgesehen von Tools, die Sicherheitslücken ausnutzen). Dabei wird ein spezieller Bootloader installiert (boot.img, der wiederum das Einschleusen des Root-Binaries (su) erlaubt. Das Custom Recovery dient also dazu den Bootlaoder zu ersetzen, der wiederum erst die Installation des Custom Recoverys möglich machte. Auch hier hat sich generell am Vorgehen zwischen Android 4.4 und 5.0 nichts geändert, bei Updates aber schon.

Eine zweite Funktion eines Custom Recoverys besteht darin, ein/eine Custom-ROM zu installieren. Dabei handelt es sich um eine komplett neue Firmware, also ein anderes Android-System. Da dabei eh keine OTA-Updates vom Hersteller mehr installiert werden können, lasse ich diesen Aspekt hier mal außen vor.

Blockbasierte OTA-Updates

Google hat das Format der Update-Dateien von Android 4.4. auf Android 5.0 grundlegend geändert. Das ist bereits seit November 2014 bekannt und diverse Medien haben auch schon darüber berichtet. Welche Auswirkungen die Änderungen aber auf den Update-Prozess haben, zeigt sich erst jetzt langsam, da immer mehr Smartphones und Tablets mit Android 5.0 im Einsatz sind. Bis zu Android 4.4 verteilte Google selbst seine Updates als dateibasiertes OTA. Nach dem Download einer OTA-Datei konnte man diese entpacken und Datei für Datei quasi schauen, was neu ist. Auch der Update-Mechanismus selbst funktionierte so: Die Dateien wurde auf dem Handy temporär entpackt, anschließend eingespielt. Bei Problemen lief das Update entweder mit einer Fehlermeldung durch oder wurde abgebrochen. Wer wollte, konnte dabei nur einige Komponenten auffrischen.

Seit Android 5 setzt Google nur noch auf blockbasierte OTA-Dateien. Die Update-Datei ist quasi ein großer Brocken, der am Stück installiert wird. Passt die Datei nicht 100 Prozent zum benutzten System, verweigert Android das Update. Hier gibt es keine Möglicheit, einzelne Komponenten vom Update auszuschließen.

An der Dateigröße hat sich durch das neue Update-Verfahren nicht viel geändert. Inkrementelle blockbasierte Update-Dateien (Deltas) sind leicht größer, da im Update selbst auch die kompletten Metaiformationen vorhanden sind (Partitionsgröße und andere Metadaten) zudem gibt es durch den benutzten Algorithmus für das Erstellen der OTA-Datei Mehrinformationen. Das Patchen von großen binären Blobs ist aber etwas CPU- und deutlich RAM-intensiver als die einfache Installation auf dem vorhandenen Dateisystem. Bei schwächeren Geräten dauert ein Update deshalb deutlich länger. Und tendenziell ist das System weniger tolerant als die dateibasierten Updates, wenn doch etwas nicht stimmt. Geht also bei einem blockbasierten Update etwas schief und bricht das Update nicht rechtzeitig ab, dann bedeutet das gleich ein großes Problem (siehe aktuelle Updates beim Nexus 7 2013 mit Bootloops).

Um den Unterschied mit einem einfachen Beispiel zu verdeutlichen stellst du dir am besten ein Lego-Auto vor, das ein neues Gehäuse bekommen soll. Während beim dateibasierten OTA-Update die neuen Legosteine einzeln auf die Räder gesetzt werden und somit dem Baumeister noch etwas Kreativität erlauben, wird beim blockbasierten Update das komplette neue Chassis auf das Fahrgestell gesetzt. Passt es nicht, kommt es zu keinem Update.

Das blockbasierte Update enthält also unter anderem auch Informationen dazu, wie groß eine Partition ist. Stimmt die Größe des Recoverys zum Beispiel nicht überein, dann bricht das Update ab. Änderungen, die unweigerlich eine solche Inkompatibilität auslösen sind:

– Installation eines Custom Recoverys

– Installation eines Custom Bootloaders (aber nicht der Entsperrvorgang selbst)

Zudem führt auch die Installation des Superuser-Binaries zu einer Inkompatibilität, da die Systempartition dadurch verändert wird und sich somit ein blockbasiertes Update nicht anwenden lässt:

„File OTA tolerates some changes to the partition, such as the addition of files that are not part of the source or target build. However, block OTA does not tolerate additions to the partition, so users will need to install a full OTA overwriting any system partition modifications) or flash a new system image to enable future OTAs.“

Sicherer Bootvorgang dank dm-verity

Eine weitere Neuerung von Android 5.0 ist Verified Boot. Sie kümmert sich darum, dass das System nur dann ohne Warnmeldung hochfährt, wenn die Bootpartition und die Recovery-Partition garantiert nicht verändert wurden. Dazu legt der Hersteller einen OEM-Schlüssel in der Bootpartition ab, der für den Integritätscheck des Bootloaders und der Recovery-Partition zum Einsatz kommt. Für Custom-ROMs und Custom-Recoverys besteht jederzeit die Möglichkeit, eigene Schlüssel zu einem Boot-Abbild oder Recovery-Abbild hinzuzufügen, ohne Warnmeldung beim Bootvorgang geht es aber nur mit dem Originalschlüssel des Herstellers.

Um von dieser neuen Sicherheitsprüfung Gebrauch machen zu können, müssen die Hersteller ihre Updates als blockbasierte OTA-Updates anbieten. Denn nur so ist sichergestellt, dass das Boot-Abbild und das Recovery-Abbild garantiert nicht verändert wurden. Denn passt der Schlüssel nicht, findet kein Update statt. Passt er hingegen, ist garantiert wieder der gleiche Schlüssel installiert.

Mit der seit Android 5.0 von Haus aus eingeschalteten Verschlüsselung sorgt das alles zusammen für ein so genanntes Trusted Execution Environment, abgekürzt TEE.

Warum die Unterschiede?

Soweit die Theorie. In der Praxis gibt es aber große Unterschiede, ob ein Gerät von Haus aus mit Android 5.0 ausgeliefert wurde oder von Android 4.4 auf Android 5.0 aktualisiert wurde. Wer Android User regelmäßig liest, kann sich bestimmt erinnern, dass Motorola bei seinen KitKat-Geräten zunächst ein Dienste-Framework-Update ausgeliefert hat und auch den Bootloader aufgefrischt hat. Das sind zwei Voraussetzungen, um Verified Boot und Blockbasierte OTAs einzusetzen.  Ebenfalls Unterschiede gibt es bei Nexus-Geräten, die Android 5.0 als OTA installiert haben (inkrementelles blockbasiertes Update) oder Android 5.0 direkt aus einem Factory Image.  Denn im ersten Fall ist mangels passendem Bootloader kein Verified Boot möglich, in letzterem kommt gleich Verified Boot zum Einsatz.

Last but not least gibt es noch die Möglichkeit, von Android 4.4 auf Android 5.0 über ein volles blockbasiertes Update aufzufrischen. Damit lässt sich auch gleich der Bootloader aktualisieren. Volle blockbasierte Updates funktionieren auch, wenn das System verändert wurde, da dabei kein Abgleich mit dem installierten System stattfindet, sondern quasi alles drübergebügelt wird. Dabei gehen alle Daten verloren.

Je nachdem, wie du dein Smartphone von Android 4.4 auf Android 5.0 angehoben hast, kann es also zu Unterschieden kommen, ob du die OTA-Updates bereits als blockbasierte BLOBs bekommst und somit mit Root/Custom-Recovery kein OTA-Update mehr möglich ist, oder eventuell doch noch dateibasierte OTA-Updates bekommst, bei denen die Größe der Recovery Partition zum Beispiel keine Rolle spielt. Für alle Geräte, die von Haus aus mit Android 5.0 ausgeliefert wurden gilt aber klar: Ab 5.0 solltest du OTA-Updates vergessen, wenn du dein Smartphone gerootet hast!

Workarounds

Nun könnte man leichtfertig sagen: macht ja nichts, ich habe ja mein Nandroid-Backup. Dieses hilft dir aber nicht weiter, da du für das Backup ja bereits ein Custom-Recovery eingesetzt hast.  Rooten solltest du unter Android 5.0 also nur, wenn du garantiert ein Abbild des kompletten Systems irgendwo gesichert hast. Nexus-Nutzer sind hier auf der sicheren Seite: Die Factory Abbilder für Nexus Geräte gibt es offiziell und öffentlich frei zum Download. Samsung-Nutzer finden üblicherweise bei sammobile.com die passende, kompette Firmware. Bei den restlichen Herstellern wird es aber schon schwieriger. An die Original-Firmware des Moto G 2013 zu gelangen, ist zum Beispiel kein Kinderspiel…

In jedem Fall musst du dich aber vom Gedanken verabschieden, dass du ohne neu Installieren auskommst. Updates sind defintitiv tot und du musst neu flashen, um die nächste Android-Version zu erhalten.

Ein weiterer Workaround besteht im Schritt weg vom Hersteller zu einer Custom-ROM (aus der Not eine Tugend machen :-). Hier gibt es weiterhin die klassischen dateibasierten Udpates und der Root-Zugriff ist zudem von Haus aus an Bord (zum Beispiel bei CyanogenMod). Somit findet also keine Änderung des Systems statt und es lassen sich auch blockbasierte Updates installieren. Es ist aber gut möglich, dass sich auch einige der ROM-Köche aus Sicherheitsgründen für die blockbasierten Updates entscheiden. Allein schon deshalb, weil der Hersteller seinen Geräten ein Bootloader-Update verpasst, das Verified Boot einführt…

Fazit

Sein Handy zu rooten, ist auch unter Android 5.0 nicht wirklich schwieriger geworden. Der Rootvorgang bzw. die Installation eines Custom Recoverys dürfte aber in praktisch allen Fällen dazu führen, dass du keine Updates mehr vom Hersteller installieren kannst. Es sei denn, du hast die Original-Firmware vom Hersteller zur Hand und kannst diese wieder installieren, wie etwa bei Samsung und bei den Nexus-Geräten. Wer nicht genau weiß, wie er wieder zurück zum Originalsystem kommt, sollte sein Android-Gerät mit Android 5 deshalb definitiv nicht rooten!