Beim Smartphone-Kauf geht es nicht nur um Display, Kamera, Akku, Speicher und Update-Zeitraum. Android 17 erinnert an eine weitere Frage: Kann man nach dem Kauf die Software entfernen, die Hersteller oder Netzbetreiber vorinstalliert haben?

Generisches Smartphone mit vorinstallierten Apps, blockierter Deinstallieren-Schaltfläche und ADB-Werkzeugkasten gegen Bloatware

Die Diskussion begann in technischen Communities, betrifft aber normale Käufer. Auf Hacker News wurden Berichte von Debloating-Tools diskutiert: Auf nicht gerooteten Android-17-Builds kann adb shell pm uninstall -k --user 0 <package> bei System-Apps mit Failure [only root can delete system app for a particular user] scheitern. Universal Android Debloater Next Generation und SmartPack PackageManager besprechen denselben Wechsel; im zitierten Android-Framework-Code findet sich die Fehlermeldung ebenfalls.

Jahrelang war ADB der Kompromiss. Der Befehl entfernte ein Systempaket nicht wirklich aus der geschützten Systempartition. Mit --user 0 verschwand es für das Hauptprofil. Für Carrier-Apps, doppelte App-Stores, Spiele, Werbedienste oder unnötige Hersteller-Tools war das oft genug.

Wenn Android 17 diesen Weg ohne Root begrenzt, bleibt vor allem Deaktivieren oder Einfrieren, sofern Paket und Hersteller es zulassen. Das ist sicherer und leichter rückgängig zu machen, aber weniger Kontrolle.

Deaktivieren ist nicht Entfernen

adb shell pm disable-user com.example.package lässt das Paket im System, deaktiviert es aber für den Nutzer. Oft verschwindet die App aus dem Launcher und stört nicht mehr. Mit adb shell pm enable com.example.package lässt sich der Zustand zurückdrehen.

Grenzen bleiben: Manche Pakete sind nicht deaktivierbar, manche OEMs aktivieren Apps nach Updates erneut, und echter Speichergewinn ist auf gesperrten Geräten begrenzt. Wer Datenschutz oder ein minimalistisches Telefon will, sieht darin nur einen Kompromiss.

Warum Käufer darauf achten sollten

Ein günstiges Android-Gerät kann gute Hardware bieten und trotzdem mit Partner-Apps, Herstellerdiensten, doppelten Stores und gesperrtem Bootloader kommen. Dann ist der reale Besitz weniger frei, als das Datenblatt vermuten lässt.

Es gibt auch ein gutes Sicherheitsargument. Systemkomponenten können WebView, Zahlungen, Kamera, Notfallwarnungen, Netzbetreiberfunktionen, Bedienhilfen oder Updates tragen. Schlechte Debloat-Listen können wichtige Funktionen beschädigen. Deshalb ist ein reversibles Standardverhalten für Tools sinnvoll.

Das Problem ist Vertrauen. Wenn derselbe Schutzwall kritische Dienste und unerwünschte kommerzielle Vorinstallationen schützt, wirkt er auf Käufer nicht nur wie Sicherheit, sondern wie nachträgliche Kontrolle durch den Anbieter.

Praktische Empfehlung

Vor Android 17 sollte man Paketlisten sichern: adb shell pm list packages > packages-before.txt. Alte Skripte nicht blind ausführen. Hinweise von Universal Android Debloater NG, SmartPack, Canta, Hail und Shizuku-Tools lesen. Eine App deaktivieren, neu starten und Anrufe, Benachrichtigungen, Kamera, Zahlungen, Karten, Bluetooth und andere wichtige Funktionen testen.

Vor dem Kauf zählen Bootloader-Entsperrung, Bloatware-Ruf der Marke, Deaktivierbarkeit in den Einstellungen, Verhalten nach OTA-Updates und eine aktive Geräte-Community. Android 17 macht Bloatware nicht automatisch unkontrollierbar. Es zeigt aber, dass Softwarekontrolle ein Kaufkriterium ist.