Samstag, 19. April 2014

Boot Loop mit Android 4.3 auf dem Galaxy S3

Wer kennt ihn nicht, den Boot Loop? Nun, die meisten Menschen, die ihr Handy-OS im Originalzustand lassen, sollten keine Bekanntschaft damit machen. Solche Phänomene wären eigentlich nur als mittelbare Folge von Modifikationen wie Rooten (Jailbreaken bei iPhones) zu erwarten.

Zwar konnte ich es irgendwann letzten Herbst tatsächlich nicht mehr lassen, mein Samsung Galaxy S3 zu rooten (“warranty voiding” hin oder her: es heißt, die Swisscom sei angeblich kulanter als Samsung), aber ein Zusammenhang zwischen Root und Boot Loop ist – auch ohne experimentelle Überprüfung – in meinem Fall eher auszuschließen:

  1. das Gerät lief nach dem Rooten und der Installation der drei, vier Apps von Google Play, die den Rootzugang benötigen, monatelang weiterhin problemlos,
  2. das erste persistierende Boot Loop trat etwa ein halbes Jahr nach dem Rooten und zirka einen Monat nach dem Update von Android Version 4.1.2 auf 4.3 (natürlich sogleich auch wieder gerootet) auf und
  3. die Ursache des Boot Loops konnte ich letzte und diese Woche schließlich experimentell nachweisen und ihn dann entsprechend reproduzieren bzw. wieder beseitigen.

Boot Loop seit Android 4.3

Die Vermutung liegt nahe, dass die Ursache des Boot Loops in Android 4.3 liegt. Vielleicht ist Root auf Android 4.3, zumindest beim S3, nicht gleich problemlos wie Android 4.1.2.? Apples iPhones sollen inzwischen ja auch Jailbreak-resistent sein.

Auf dem S3 verwende ich das gerootete original Rom (“stock rom”) meines Netzproviders (Swisscom, inklusive dessen Logo beim Booten). Obwohl dieser Anfang November 2013 das Update 4.3 zum Download bereit gestellt hatte, gab es damit weltweit Probleme auf dem S3: bevor ich es installieren konnte, hatte Samsung das Update wieder zurück gezogen. Den Rückmeldungen der S3-Besitzer war unter anderem zu entnehmen, dass nach dem Update der Boot viel länger dauert.
Könnte es sein, dass das, was ich – ein recht ungeduldiger Mensch – subjektiv als “Boot Loop” erlebte, gar kein Boot Loop war sondern lediglich die mit dem Update 4.3 verlängerte Bootzeit? Dass ich das Gerät aus Ungeduld jeweils einfach zu früh abschaltete, dass ich nur Geduld aufzubringen gebraucht hätte, das Ende der Bootsequenz abzuwarten? In der Tat, das hätte theoretisch auch die Ursache sein können. Winking smile Bloß: wenn das Gerät vor dem Schwimmen gestartet wird und nach dem Schwimmen immer noch das Boot-Logo zeigt, versucht es über Vernunft lange zu booten.

Interessant war zunächst, dass es sich manchmal booten ließ, manchmal nicht. Manchmal ließ es sich nach einem Löschen des Cache-Speichers wieder starten. Manchmal nützte auch das nichts mehr. Manchmal half erst das Löschen des Dalvik-Caches. Es blieb am Schluss jeweils nichts anderes übrig, als das Phone jeweils mit einem CWM-Backup-Image (und die seit dem letzten CWM-Backup entstandenen Daten mit Helium) wieder herzustellen. Nachdem ich das System so einmal komplett neu aufgesetzt hatte, das Problem aber nach kurzer Zeit wieder entstand, hieß es seit etwa Anfang März letztlich: Jeder “Boot” jeweils ein Recovery von ein bis zwei Stunden Dauer? Das ist für kurze Zeit, als Notlösung machbar. Aber wie froh war ich, als endlich Ostern und damit Zeit kam, mich dem Problem mit der nötigen Tiefe zu widmen…

Boot Loop als Folge von Apps auf externer SD-Karte?

Da der allererste Boot Loop auftrat, nachdem ich einige Apps mit der in Android 4.3 neuen entsprechenden System-Funktion auf die externe SD-Karte verschoben hatte, und dann wieder verschwand, als ich eine fragliche App wieder auf den internen Speicher zurückverschoben hatte, schwante mir, dass ein Zusammenhang mit dem Verschieben von Apps auf die externe Karte bestehen könnte. Vielleicht waren einige Apps nicht kompatibel damit? Diesbezügliche Gewissheit erhielt ich, als der Boot Loop nach dem Verschieben mehrerer Apps auf die externe SD-Karte erneut auftrat.

Nun stand ich vor einem großen Problem: mit 16GB internem Speicher verfügte mein S3 anscheinend nicht über genug Speicher für all meine Apps. Es bräuchte mindestens 32GB. Eine Neuanschaffung steht aber außer Frage, sie wäre unwirtschaftlich. Deshalb hatte ich so viele Apps wie möglich auf die externe SD-Karte ausgelagert, was zum Boot Loop führte. Ein Teil der Apps musste also schlicht weg. Aus diesem Grund musste ich Prioritäten setzen: Welche Apps benötige ich wirklich jederzeit bei mir (und somit auf dem Phone), bei welchen Apps genügt eine Installation auf dem Tablet?

Problemlösung: Aufräumen des Phones

Es war eine in gewissem Sinn kontemplative Aufgabe, auch innerlich befreiend, Apps, die ich ein paar mal ausprobiert habe und kaum je wieder benutzen würde, zu löschen. Daneben gibt es eine Menge Apps, die ich nur noch auf dem Tablet nutze und die ich nur noch notfallmäßig auf dem Phone benutzen würde.
Trotzdem blieb auch nach dieser Bereinigung kaum Platz auf der internen SD-Karte des S3. Zwar benötigten die verbleibenden, nun alle auf dem internen Speicher abgelegten Apps zusammen laut App-Manager nur noch 1.9GB, aber das S3 warnte trotzdem einmal sogar, dass nur noch 45MB auf der internen SD-Karte frei seien. Irgendwo musste sich demnach Datenmüll angestaut haben, den nicht einmal die “Clean Master” App aufzuspüren und zu löschen vermochte.

Ein Problem waren Gallery-Thumbnails, die Android von auf dem Gerät oder auf der externen SD-Karte gespeicherten Bildern automatisch erstellt. Da auf meiner externen 64GB SD-Karte recht viele Fotos vorhanden waren (nebst Eye-Fi- unter anderem auch synchronisierte Picasa- und Facebook-Alben), belegten die Gallery-Thumbnails etwas mehr als 3GB Speicher, unerklärlicherweise auch nachdem ich sämtliche Fotos von der externen wie auch der internen SD-Karte gelöscht hatte. Diese 3GB ließen sich nicht tilgen, wie oft ich es auch versuchte, im besten Fall ließen sie sich auf 1.5GB reduzieren (später fand ich heraus, dass die automatische Synchronisation von Picasa-Webalben dafür verantwortlich war).
Ein weiteres Problem waren Daten, die zu nicht mehr benötigten, gelöschten Apps gehörten. Diese waren im (ohne Rootrechte nicht bearbeitbaren) Systembereich der internen SD-Karte abgelegt, und Android hatte sie beim Löschen der Apps offenbar nicht mitgelöscht. Ein Fall war besonders interessant, da dasselbe obsolete Datenpaket sogar doppelt vorhanden war und so etwa 650 statt nur 325MB belegte. Diese Datenpakete entdeckte ich mit der App “DiskUsage”. Um sie zu löschen, sind Rootrechte erforderlich, alternativ bietet sich ein Factory-Reset bzw. ein Wipen und Neuaufsetzen des Geräts an.

Fazit: Externe SD-Karte ggf. erst nach dem Booten einsetzen

Nachdem ich das Gerät bereinigt hatte, blieben – mit sämtlichen von mir als essentiell einstuften Apps installiert – rund 3.5GB interner SD-Speicher frei. Dies gestattete mir sogar, einige Apps, die auf dem Phone nur nice to have sind, wieder zu installieren, worauf noch 2GB frei waren (die sehr empfehlenswerte Fitness-App “The Walk” beispielsweise belegt rund 1GB). Dies lässt genug internen Speicherplatz für Apps, die Daten nur auf der internen SD-Karte anlegen können.
Schließlich verschob ich experimentell wieder einige Apps auf die externe SD-Karte. Und tatsächlich: Der Boot blieb wieder jedes Mal hängen (wenn es zu viele Apps auf der externen SD waren). Erst nachdem ich sie wieder auf die interne SD zurück verschoben hatte, bootete das S3 vollständig und auch relativ zügig.

Es lassen sich wohl einige Apps auf der externen SD ablegen und das S3 bootet trotzdem, aber die Erfahrung zeigt jetzt, dass es nicht zu viele sein dürfen. Ob ein Zusammenhang zu bestimmten Apps besteht, habe ich nicht eruiert; jedenfalls können auch Apps ohne Widgets oder Teilen-Funktion den Boot blockieren, wenn sie auf der externen SD-Karte sind.
Beim so bedingten Boot Loop hilft nur, die SD-Karte für den Boot heraus zu nehmen und danach wieder einzusetzen. Die externe SD-Karte lässt sich problemlos erst nach dem Boot einstecken.



Copyright © Christian A. Natiez (Schweiz)