Letztens teilte mir mein Nokia 2.2 mit, daß es keine Apps mehr updaten könne, weil zu wenig Speicher vorhanden sei. Das Gerät bietet für Apps gerade mal 6,5 GB Speicher. Ich hatte schon irgendwie damit gerechnet, daß es in diesem Jahr soweit sein würde: Das Gerät hatte ich Ende 2019 mit Android 9 gekauft, und es hat System-Updates bis Android 11 bekommen. Die Apps dagegen bekamen weiterhin Updates, aber der Speicherbedarf wurde immer größer. Es hätte aber nicht jetzt schon sein müssen …
Als sich das Problem vor längerer Zeit zum ersten Mal zeigte, hatte ich dem damit abgeholfen, daß ich einige der mitgelieferten und nicht deinstallierbaren Apps deaktiviert hatte. Damit fallen zumindest deren auch immer größer werdende Update-Versionen raus. Nun hat das nicht mehr gereicht.
Ich versuchte zunächst, mir mit der Deinstallation von drei Apps zu behelfen, von denen ich eine sowieso nicht mehr brauchte. Die zwei weiteren habe ich in den letzten Monaten nicht mehr verwendet – ich war ja auch wegen der Operation erstmal nicht viel unterwegs gewesen, da waren c:geo und transportr erstmal nutzlos. Allerdings möchte ich nicht dauerhaft darauf verzichten, zumal ich mir gerade wieder das Deutschland-Ticket geklickt habe und hoffentlich bald wieder mehr unterwegs sein kann. Die Deinstallation ermöglichte bei zwei Apps das Update, und dann hieß es schon wieder: Nicht genügend Speicherplatz. Nun gibt es zwei Möglichkeiten:
- Ich kaufe mir ein neues Smartphone. Mein Konto sagt, daß es wohl wieder nur ein günstiges Android-Smartphone werden kann. Ob es dann genügend Speicher hat, um nicht in zwei, drei Jahren auf dasselbe Problem zu stoßen, ist dann fraglich.
- Ich versuche, mit Hilfe von ADB, einem Entwicklungstool, die eigentlich nicht deinstallierbaren Apps doch zu deinstallieren. Zumindest die, von denen ich sicher annehmen kann, daß es mir nichts zerschießt, wenn sie nicht mehr vorhanden sind.
Ich bilde mir ja ein, nicht wirklich viel installiert zu haben. Wenn ich in der Vergangenheit die Bilder aus der Werbung für Smartphones gesehen habe, wie da die Anzeige mit Symbolen für speicherhungrige Apps gefüllt ist, dann habe ich mich immer gefragt, wo die den Speicher dafür hernehmen wollen. Denn auf die Speicherkarte gehen die Apps ja gerade nicht, selbst wenn man das konfigurieren kann, oder nur mit ihren Konfigurations- und Arbeitsdaten, aber eben nicht mit den eigentlichen Programmen.
Was jetzt noch drauf ist:
- TooGoodToGo (125 MB)
- DHL-Paket-App (119 MB)
- Signal (206 MB)
- Tusky (82,73 MB)
- DuckDuckGo-Browser (132 MB)
- FDroid (102 MB), daraus
- Notizen (19,62 MB)
- andOTP (15,83 MB)
- Galerie (50,23 MB)
- GPS-Cockpit (5,3 MB)
- ConnectBot (12,98 MB)
Allein die TooGoodToGo-App belegt seit dem letzten Update mal locker-flockige 40 MB mehr. Bei Tusky waren es fast 20 MB, bei Signal 6 MB und beim DuckDuckGo-Browser 2 MB. Die Alternative zu letzterem wäre, ihn runterzuwerfen und den vorinstallierten Chrome zu verwenden – danke, aber nein danke.
Als ich nun nach aktuellen Smartphones fragte, bekam ich den Rat, es doch erstmal mit ADB zu versuchen. Mit diesem Entwickler-Tool ist es möglich, über einen PC oder Notebook Apps vom Smartphone zu löschen oder welche zu installieren. Bevor ich Geld ausgebe, wollte ich es erstmal damit versuchen.
Der Anleitung gemäß installierte ich die notwendigen Pakete. Dabei lernte ich, daß das dort genannte Paket android-tools-adb in Debian so nicht existiert, aber das dortige Paket adb dieses ersetzt. Prima, also habe ich installiert:
:~$ apt install adb android-sdk-platform-tools-common pidcat Vorbereitung zum Entpacken von .../0-android-liblog_1%3a10.0.0+r36-7_amd64.deb ... Entpacken von android-liblog (1:10.0.0+r36-7) ... Vormals nicht ausgewähltes Paket android-libbase wird gewählt. Vorbereitung zum Entpacken von .../1-android-libbase_1%3a10.0.0+r36-7_amd64.deb ... Entpacken von android-libbase (1:10.0.0+r36-7) ... Vormals nicht ausgewähltes Paket android-libboringssl wird gewählt. Vorbereitung zum Entpacken von .../2-android-libboringssl_10.0.0+r36-1_amd64.deb ... Entpacken von android-libboringssl (10.0.0+r36-1) ... Vormals nicht ausgewähltes Paket android-libcrypto-utils wird gewählt. Vorbereitung zum Entpacken von .../3-android-libcrypto-utils_1%3a10.0.0+r36-7_amd64.deb ... Entpacken von android-libcrypto-utils (1:10.0.0+r36-7) ... Vormals nicht ausgewähltes Paket android-libcutils wird gewählt. Vorbereitung zum Entpacken von .../4-android-libcutils_1%3a10.0.0+r36-7_amd64.deb ... Entpacken von android-libcutils (1:10.0.0+r36-7) ... Vormals nicht ausgewähltes Paket android-libadb wird gewählt. Vorbereitung zum Entpacken von .../5-android-libadb_1%3a10.0.0+r36-7_amd64.deb ... Entpacken von android-libadb (1:10.0.0+r36-7) ... Vormals nicht ausgewähltes Paket android-sdk-platform-tools-common wird gewählt. Vorbereitung zum Entpacken von .../6-android-sdk-platform-tools-common_28.0.2+3_all.deb ... Entpacken von android-sdk-platform-tools-common (28.0.2+3) ... Vormals nicht ausgewähltes Paket adb wird gewählt. Vorbereitung zum Entpacken von .../7-adb_1%3a10.0.0+r36-7_amd64.deb ... Entpacken von adb (1:10.0.0+r36-7) ... Vormals nicht ausgewähltes Paket pidcat wird gewählt. Vorbereitung zum Entpacken von .../8-pidcat_2.1.0-4_all.deb ... Entpacken von pidcat (2.1.0-4) ... android-sdk-platform-tools-common (28.0.2+3) wird eingerichtet ... android-liblog (1:10.0.0+r36-7) wird eingerichtet ... pidcat (2.1.0-4) wird eingerichtet ... android-libboringssl (10.0.0+r36-1) wird eingerichtet ... android-libcrypto-utils (1:10.0.0+r36-7) wird eingerichtet ... android-libbase (1:10.0.0+r36-7) wird eingerichtet ... android-libcutils (1:10.0.0+r36-7) wird eingerichtet ... android-libadb (1:10.0.0+r36-7) wird eingerichtet ... adb (1:10.0.0+r36-7) wird eingerichtet ... Trigger für man-db (2.9.4-2) werden verarbeitet ... Trigger für libc-bin (2.31-13+deb11u8) werden verarbeitet ...
So weit, so gut. Als nächstes habe ich das Nokia per USB mit dem PC verbunden und es in den Entwickler-Modus versetzt. Was mir nicht ganz klar war: Welchen USB-Modus ich wählen muß. Ich habe erstmal die normale Datei-Übertragung gewählt.
Dann fing der Spaß an:
:~# adb devices List of devices attached :~#
Davor hatte ich es bereits mit meinem User-Account versucht, mit dem gleichen Ergebnis: adb sieht das Smartphone nicht.
Der Versuch, die Steuerungs-Richtung von Smartphone zu PC zu ändern, scheiterte am Smartphone: Das Nokia behauptete, das sei nicht möglich. Ich vermutete, daß dazu auf dem PC ein Daemon laufen müßte, der die Steuerung übernimmt. Und tatsächlich, der ist da auch:
:~$ ps fax | grep adb 14795 pts/0 S+ 0:00 | \_ grep adb 12653 ? Ssl 0:01 adb -L tcp:5037 fork-server server --reply-fd 4
Scheinbar mögen sich die beiden aber wohl nicht. Der Daemon scheint auch kein Log zu schreiben, denn weder das /var/log/daemon.log noch /var/log/messages wissen irgendwas von dem Daemon. Oder er hat von dem Nokia noch gar nichts mitbekommen, obwohl dessen An- und Abmeldungen in den üblichen Logs aufzeichnet wurden.
Ich fragte das schlaue Fediverse:
[…]
Frage ist, welchen Modus für USB ich am Smartphone einstellen muß. Angeboten werden:
- Dateiübertragung
- USB-Tethering
- MIDI
- PTP
- keine Dateiübertragung
Bisher habe ich Dateiübertragung gewählt.
Außerdem wird gefragt, welches Gerät die Verbindung steuern soll: das Smartphone oder der PC. Die Umstellung auf PC funktioniert aber nicht, obwohl der adb-daemon läuft.
Wat wollen die noch von mir?
@atarifrosch uff. Immer "keine Dateiübertragung", und adb shell als root in den Entwickleroptionen anmachen, hat früher gereicht. Dat wird auch immer schlimmer.
Steuern? Ist das so ein USB-C-Ding? Falls ja, der Computer, denke ich.
Auf „keine Dateiübertragung“ umzustellen half auch nicht: Das Nokia wurde weiterhin nicht gesehen und ließ sich weiterhin nicht auf Steuerung vom Computer umstellen.
Neuer Versuch, zehn Tage später: Ich hatte über Mastodon noch einen Hinweis auf die „Entwickler-Optionen“ auf dem Smartphone bekommen. Diese finden sich in den Einstellungen unter „System“. Hier konnte ich das USB-Debugging aktivieren. Damit kam ich einen Schritt weiter:
:~# adb devices List of devices attached HZAL1670CAK11400166 device
Schau an, da isses ja.
Das war's dann aber auch schon wieder. Der Anleitung nach sollte ich jetzt mit
adb shell "pm list packages"
die Liste der installierten Apps aufrufen können. Also versuchte ich mal, eine App zu entsorgen:
:~# adb uninstall com.google.android.youtube Failure [DELETE_FAILED_INTERNAL_ERROR] :~# adb shell "pm list packages" | grep chrome package:com.android.chrome :~# adb uninstall com.android.chrome Failure [DELETE_FAILED_INTERNAL_ERROR]
Hm, da fehlt wohl immer noch was? Oder geht das unter Android 11 noch nicht?
Offenbar muß man erst diesen Trick kennen. Der Packet-Manager ist der Ausführung dieses Befehls nämlich nicht abgeneigt:
:~# adb shell WSP_sprout:/ $ pm uninstall --user 0 com.android.chrome Success
Und wech isser.
Weiterhin weggeworfen habe ich:
- com.google.android.apps.wellbeing
- com.google.android.apps.photo
- com.google.android.youtube
Außerdem habe ich in den Entwickler-Einstellungen das Speichern von Apps auf der Speicherkarte freigegeben. Daß das darüber geht, wußte ich bisher auch noch nicht. Ob das tatsächlich Auswirkungen hat und welche die Apps das „Angebot“ annehmen, wird sich erst noch zeigen.
Und siehe da, ich kann die anstehenden Apps wieder updaten. Wie lange das so gut geht, ist natürlich 'ne andere Frage. Vermutlich brauche ich trotzdem noch in diesem Jahr ein aktuelleres Smartphone, vor allem mit mehr Speicher.