Unweigerlich lief mein gutes altes
Samsung Galaxy SII GT-I9100 voll. Es war nicht mehr zu ignorieren: Neue Apps liessen sich wegen Platzmangels unter /data
nicht mehr installieren, App-Updates schlugen aus dem gleichen Grund fehl, und bereits installierte Applikationen
wurden zickig.
Zum Beispiel zeigt die Kamera-App nach dem Start gelegentlich keine Buttons mehr an, so dass mit ihr nicht viel anzufangen war.
Ob auch das mit dem Speichermangel zu tun hat? Keine Ahnung - aber es war einfach Zeit, mal wieder aufzuräumen. Eine
Randbedingung machte die Aufgabe schwierig: Ich wollte mein Telefon dazu nicht ohne Not "rooten"...
Bevor ich mir Rootzugang verschaffe, wollte ich zuerst ein paar (vermeintlich?) einfachere Ansätze durchprobieren.
Methode 1:
SD Maid
SD Maid hatte ich vor einer Weile schon installiert und gekauft - ich kann die Applikation auch weiterempfehlen,
denn sie findet immer wieder mal beseitigenswerte Reste oder aber hilft bei der Analyse. Im vorliegenden Fall
zeigte sie an, dass von den knapp 2 GB Platz unter
/data
nur noch wenige Prozent frei waren. Ich hatte mir vorher
angelesen, dass Android-Applikationen sich normalerweise hier installieren. Man kann Applikationen zwar auch auf die SD-Karte
schieben, aber - so warnten die einschlägigen Artikel - dennoch könnte es sein, dass die verschobenen Applikationen
Teile ihrer Daten weiter unter
/data
ablegten.
Ebenfalls erwähnenswert ist in diesem Zusammenhang das kleine, aber feine
Diskusage, das
schnell einen grafischen Überblick der Speichersituation verschafft.
Methode 2:
adb shell
Vor zwei Jahren hatte ich mir Android-Entwicklergrundwissen angelesen und dabei auch das Android SDK installiert,
zu dem auch
adb
gehört. Nach Aktivieren des "USB debugging" in den Developer Options meines Telefons
entspann sich folgender, eher unbefriedigender Dialog mit meinem Telefon:
clausb:platform-tools clausb$ ./adb shell
shell@android:/ $ ls /data
opendir failed, Permission denied
"Think, McFly, think!" Eigentlich klar. Ohne Rootrechte auf dem Telefon geht halt auch mittels
adb
nicht viel. Hmpf.
(Guter Grundlagenartikel zum Thema:
http://techblogon.com/android-file-system-structure-architecture-layout-details/)
Methode 3:
SysDump
Auf dem Samsung-Telefon kann man durch Eingabe von
*#9900# auf der Telefontastatur ein verstecktes
Programm namens
SysDump starten. Offenbar dient dieses Tool der Analyse von Kernelproblemen. Es bietet
aber auch eine Option namens "Delete dumpstate/logcat", die alte Dumps und Logfiles entfernt.
Wie der
Artikel unter
http://www.guyrutenberg.com/2013/11/01/galaxy-s2-clearing-logs-on-an-unrooted-phone/
und die Diskussion unter
http://androidforums.com/threads/low-on-space-system-data-huge.278837/ zeigen,
hat diese Option schon so manchem geholfen - und so war es auch bei mir. Nach "Delete dumpstate/logcat"
waren wieder deutlich mehr als 30% des Systembereichs unter
/data
frei!
Bei der Recherche kam mir auch
Root Cleaner unter. Das ist eine
Applikation, die sich eigens auf das Aufräumen von Systemdaten spezialisiert und vermutlich deutlich über das
Löschen von Dumpfiles hinausgeht. Guter Ansatz - aber auch diese App braucht Root-Rechte.
Methode 4: Applikationen deinstallieren
Nicht originell, aber der Vollständigkeit halber muss es erwähnt werden: Natürlich fanden sich auch auf meinem
Telefon Apps, die ich so gut wie nie nutze, so dass sie verzichtbar waren.
Methode 5: Applikationen abspecken
Praktisch alle Apps legen lokal Cachedaten an und verbrauchen damit eventuell Platz in
/data
. Der Applikationsmanager
von Android bietet für jede Applikation Optionen zum Löschen lokaler App-Daten an. Besonders ausgeprägt ist der
App-Cache natürlich bei Webbrowsern wie Firefox. Hier verstecken sich die Optionen zum Löschen des Caches in
den
privacy options.
Fazit: Ein ganzer Abend war verdaddelt mit Hausmeistertätigkeiten, aber am Ende hatte
/data
wieder fast 40% freien Speicher.
Mit der Folge, dass etliche automatische App-Updates losrappelten, die schon lange sehnsüchtig darauf gewartet hatten,
dass sich ihnen der entsprechende Platz böte - und diesmal erfolgreich waren.