- Universal Android Debloater GUI ist ein Tool, das das bestehende UAD project vollständig in Rust neu geschrieben hat und darauf abzielt, unnötige oder wenig bekannte Android-System-Apps zu entfernen, um Privatsphäre und Akkulaufzeit zu verbessern
- Systempakete lassen sich ohne Root entfernen/deaktivieren und wiederherstellen/aktivieren; unterstützt werden Multi-User, Multi-Device, Export/Import von Auswahlen und ein Arbeitsprotokoll
- Die Pakete sind nach Möglichkeit dokumentiert, um bei der Einschätzung zu helfen, ob sie entfernt werden können; das Entfernen essenzieller Systempakete kann jedoch zu einem Bootloop führen
- Auf Geräten ohne Root lassen sich System-Apps nicht wirklich vollständig entfernen; nach OEM-Updates können einige „entfernte“ System-Apps erneut installiert werden, sodass das Tool erneut ausgeführt werden muss
- Die Unterstützung umfasst Google/Facebook/Amazon/Microsoft, AOSP, OEMs, Mobilfunkanbieter, Qualcomm/Mediatek usw.; zudem werden separate Debloat-Listen nach Hersteller und Mobilfunkanbieter bereitgestellt
Zweck von Universal Android Debloater GUI
- Universal Android Debloater GUI ist ein Projekt, das das UAD project vollständig in Rust neu geschrieben hat
- Ziel ist es, unnötige und wenig bekannte System-Apps zu entfernen, um Privatsphäre und Akkuleistung zu verbessern
- Das Entfernen von System-Apps kann auch zur Verbesserung der Sicherheit beitragen, indem die Angriffsfläche reduziert wird
- Das Projekt befindet sich noch in einer frühen Entwicklungsphase; das Prüfen von Issues und Beiträge werden empfohlen
Sicherheit und wichtige Warnhinweise
- Die Nutzung erfolgt auf eigene Verantwortung; das Projekt übernimmt keine Haftung für mögliche Folgen am Telefon
- Pakete sind nach Möglichkeit dokumentiert, damit besser verstanden werden kann, ob sie gelöscht werden können
- Das schlimmste Problem ist ein Bootloop, wenn essenzielle Systempakete entfernt werden, die zum Starten benötigt werden
- Nach etwa 5 fehlgeschlagenen Startversuchen bootet das Telefon automatisch in den Wiederherstellungsmodus
- In diesem Fall muss ein Zurücksetzen auf Werkseinstellungen durchgeführt werden
- Zuvor sollte unbedingt ein Backup erstellt werden
- Es wird ausdrücklich darauf hingewiesen, dass dieses Tool ein Gerät nicht bricken kann
- Ohne Root können System-Apps nicht wirklich vollständig entfernt werden; weitere Details finden sich in den FAQ
Unterstützte Funktionen
- Unterstützung für Uninstall/Disable und Restore/Enable von Systempaketen
- Multi-User-Support, etwa für Apps im Arbeitsprofil
- Auswahl kann als
uad_exported_selection.txtexportiert und importiert werden - Multi-Device-Support für das gleichzeitige Verbinden mehrerer Telefone
- Alle Aktionen werden protokolliert, damit Nutzer nicht vergessen, was sie ausgeführt haben
Umfang der Debloat-Listen
- Die Universal Debloat Lists umfassen die folgenden Kategorien
- GFAM: Google, Facebook, Amazon, Microsoft
- AOSP
- Hersteller (OEM)
- Mobilfunkanbieter
- Qualcomm, Mediatek, Sonstige
- Die Debloat-Liste für Hersteller unterstützt Asus, LG, Google, Fairphone, Huawei, Motorola, Nokia, OnePlus, Oppo, Realme, Samsung, Sony, Tecno, Unihertz, Vivo/iQOO, Xiaomi, ZTE und weitere
- Archos, Blackberry, Gionee, iQOO, HTC, TCL und Wiko sind in der Herstellerliste noch nicht geprüft
- Die Debloat-Liste für Mobilfunkanbieter umfasst die folgenden Länder und Anbieter
- France: Orange, SFR, Free, Bouygues
- USA: T-Mobile, Verizon, Sprint, AT&T
- Germany: Telekom
- UK: EE
Vorgehensweise und Einschränkungen
- Zunächst sollten die FAQ gelesen und die Daten gesichert werden
- Auf dem Smartphone müssen die Developer Options aktiviert und im Entwicklerbereich USB Debugging eingeschaltet werden
- In den Einstellungen muss die Verknüpfung mit dem OEM-Konto aufgehoben werden
- Wenn das OEM-Kontopaket gelöscht wird, kann das Telefon die Identität des Nutzers möglicherweise nicht mehr zuordnen und auf dem Sperrbildschirm blockieren
- ADB muss installiert sein
- Unter Linux wird je nach Distribution
android-sdk-platform-toolsoderandroid-toolsüber den Paketmanager installiert - Unter macOS wird
android-platform-toolsper Homebrew installiert - Unter Windows werden die android platform tools heruntergeladen, entpackt und zum PATH hinzugefügt, oder UAD wird im selben Verzeichnis ausgeführt
- Unter Windows sollten die USB drivers für das Gerät installiert und die Erkennung mit
adb devicesgeprüft werden
- Unter Linux wird je nach Distribution
- Die neueste UAD-GUI-Version für das jeweilige Betriebssystem kann unter releases heruntergeladen werden
- Die
opengl-Version sollte nur verwendet werden, wenn die Standardversion mit Vulkan-Backend nicht startet
- Die
- Nutzer chinesischer Smartphones benötigen zum Entfernen einiger Standard-Apps möglicherweise die AOSP-Liste
- Besonders, weil chinesische Hersteller wie Xiaomi und Huawei für eigene modifizierte, Closed-Source-Apps AOSP-Paketnamen verwendet haben
- Wenn ein OEM Updates für das Telefon verteilt, können einige „entfernte“ System-Apps erneut installiert werden; dann muss diese Software erneut ausgeführt werden
Mitwirken
- Das Projekt ist ein Community-Projekt; Hinweise zum Beitragen sind unter How to contribute zusammengefasst
1 Kommentare
Hacker-News-Kommentare
Ich habe kürzlich einem Verwandten ein Samsung-Smartphone der Mittelklasse zum vollen Preis gekauft, und es war kaum zu glauben, wie viele vorinstallierte Apps darauf waren.
Mehrere soziale Netzwerke und Shopping-Apps waren bereits installiert, dazu jede Menge Samsung-Apps, die das Google-App-Bundle unbeholfen duplizierten.
Der gesamte Ersteinrichtungsprozess war voller Dark Patterns, die offenbar darauf ausgelegt waren, möglichst viele Daten abzugreifen, sodass es für normale Nutzer schwer wirkte, ohne etwas zu übersehen hindurchzukommen.
In der Datenschutzerklärung dieses Unternehmens stand, dass die Daten verwendet würden, um Interessen, Sozialleben, Intelligenzniveau und Bildungsstand zu schätzen und sie unter anderem für „Marktforschung“ zu verkaufen.
Nutzer kommen kaum auf die Idee, dass die standardmäßig auf dem Smartphone installierte Tastatur ihre SMS und E-Mails von Dritten mitlesen lässt.
Ich habe es nur zufällig bemerkt, als ich eine Taste lange gedrückt hielt, das Fenster „about samsung keyboard“ öffnete, dort der Datenschutzerklärung folgte und erst dann sah, an welches Unternehmen die Tastenanschläge gesendet wurden.
Ich habe sofort zu einer Open-Source-Tastatur gewechselt, und vermutlich gerade weil sie Eingaben aller Nutzer sammelt, waren Rechtschreibprüfung und Wortvorhersage der Samsung-Tastatur wirklich gut.
Meine letzten drei Geräte waren in der EU verkaufte Samsung-S-Serie-Modelle, und als „vorinstallierte Drittanbieter-Apps“ würde ich dort höchstens Facebook und MS Office zählen, die sich beide leicht entfernen ließen.
Die Samsung-Alternativ-Apps sind Geschmackssache, aber ich fand sie benutzerfreundlicher als die Google-„Originale“.
Nach kurzem Ausprobieren anderer Marken würde ich sagen, dass Samsung bei Software und Nutzererlebnis unter den Android-Optionen ziemlich gut dasteht.
Bei einem 1200-Dollar-Flaggschiffgerät ist das beschämend.
Dort heißt es: „Wenn Sie sich auf Ihrem Android-Gerät nicht dafür entschieden haben, ein Microsoft SwiftKey Account zu verwenden, werden alle von Microsoft SwiftKey erzeugten persönlichen und sprachlichen Daten lokal auf dem Gerät gespeichert und nicht übertragen.“
Ich nutze sie, weil sie nahtlos zwischen aktivierten Sprachen wechselt, und Sätze wie „meet me at Østerport Station“ lassen sich damit flüssig eingeben.
Das Problem sind aber die vorinstallierten Apps, daher führe ich bei Samsung-Smartphones als Erstes
pm uninstall –k ––user 0aus.Das verlinkte Tool macht im Grunde dasselbe, nur benutzerfreundlicher, aber Dinge wie Samsung-Account- oder Knox-Komponenten lassen sich ohne Custom ROM immer noch nicht entfernen.
Dieses Projekt wird seit einem Jahr nicht mehr gepflegt.
Den aktuell gepflegten Fork gibt es unter https://github.com/Universal-Debloater-Alliance/universal-an...
Die in diesem Projekt verwendeten Android-Befehle sehen ungefähr so aus:
dpkg --get-selections:adb shell pm list packages | sortdpkg -r:adb shell pm uninstall -k --user 0Um Statusleisten-Symbole auszublenden, kann man je nach Version
adb shell dumpsys activity service SystemUIServiceausführen, nach „icon slots: “ suchen, die Namen nachsehen und dann etwa mitadb shell settings put secure icon_blacklist battery,wifi,clock, ...setzen.Dieser Befehl überschreibt die bestehende Sperrliste mit der neuen Liste.
Zum Beispiel weiß der Großteil von Googles Android- und Pixel-Kernteam offenbar, wie praktisch getrennte Wi‑Fi- und Daten-Umschalter sind, hat im eigentlichen Produkt aber nur eine zusammengeführte Schnelleinstellungs-Kachel für beides ausgeliefert.
Über eine versteckte Einstellung kann man den Zwei-Kachel-Modus trotzdem wieder aktivieren, und ich verstehe nicht, warum so etwas bei Google so oft passiert.
Ich habe mich seit einigen Wochen gefragt, was aus der Entwicklung von Open-Source-Freie-Software-Betriebssystemen für Mobilgeräte geworden ist.
Ich frage mich, warum Betriebssysteme wie GrapheneOS und CalyxOS nur auf von Alphabet Inc. hergestellten Telefonen laufen und nicht auf anderen Geräten, und wo Betriebssysteme geblieben sind, die wie bei der Linux-Entwicklung früher viele Hardware-Varianten zusammenführen und Treiber sowie Unterstützung für fast alle Geräte bereitstellen.
Ich frage mich, ob die Hardware-Industrie für mobile Computer so verängstigt und abgeschottet ist, dass Nutzer ihre Geräte nicht wirklich besitzen, sondern am Ende Geräte verwenden, die jemand anderem gehören.
Oder ob es einen anderen Grund dafür gibt, dass es keine Betriebssysteme gibt, die viele Geräte unterstützen, oder ob ich etwas übersehe.
Auch GrapheneOS oder CalyxOS haben keinen Zugriff auf unverzichtbare Treiber und holen sich deshalb Binär-Blobs aus den Original-Images, die sie dann mit ausliefern.
Deshalb sind solche Projekte voller Closed-Source-Kernel-Treiber und an bestimmte Kernel-Versionen gebunden, um diese Binärtreiber nutzen zu können.
Letztlich besteht das Maximum dessen, was Open-Source-Versionen leisten können, nur darin, ein anderes Bündel von „System-Apps“ auszuwählen; tatsächlich ist das kaum mehr als ein wenig besseres Theme-Wechseln, so die Behauptung.
Um ein bestimmtes Gerät X zu unterstützen, muss man sich die Binär-Blobs per Root-Exploit beschaffen und kann sie danach für dieses Gerät verteilen.
Auch https://grapheneos.org/faq#supported-devices kann ich nicht akzeptieren.
Wenn ich mich richtig erinnere, wurde Alphabet/Google dafür finanziert, das Android-Betriebssystem zu verbreiten, brachte eine Zeit lang auch eigene Hardware-Telefone heraus, verschwand dann wieder und ließ andere Unternehmen weitermachen, nur um später zurückzukehren und den Eindruck zu erwecken, den Vorsprung durch Ausnutzung der Bemühungen anderer Hersteller gewonnen zu haben.
Wenn das Betriebssystem dann aber nur auf Google-Telefonen existiert und nicht auf anderen Geräten, weiß ich nicht, ob das normal sein soll, und es fühlt sich an, als hätte man sich auf feige Weise die Arbeit anderer unter den Nagel gerissen.
Die Geräteliste auf https://calyxos.org/#Devices ist zwar etwas länger als die frühere unter http://web.archive.org/web/20230605161332/https://calyxos.or..., aber mit OpenWRT, HyperWRT, DD-WRT oder Tomato ist das nicht vergleichbar.
Deshalb vertraue ich GrapheneOS oder CalyxOS nicht und würde bei Telefonen gern eine ähnliche Entwicklung sehen wie bei Wi-Fi-Routern, bei denen mehrere Open-Source-Firmwares viele verschiedene Geräte unterstützten.
Ich habe auf einem auf Werkseinstellungen zurückgesetzten Xiaomi einmal eine dieser Listen angewendet, und nach dem Neustart war das Gerät sofort kaputt.
Direkt nach dem Login stürzte alles sofort ab und war unbenutzbar; ich konnte es am Ende zwar reparieren, habe dabei aber gelernt, vorsichtig zu sein.
Was bei einem Modell unverzichtbar ist, kann bei einem anderen Modell eine vorinstallierte App sein.
Ich verstehe nicht, warum das nötig ist.
In den Einstellungen des Telefons kann man Apps doch direkt deaktivieren; unklar ist, was dieses Tool darüber hinaus bringt.
In der FAQ ist davon die Rede, zusätzlich im Benutzerprofil zu „entfernen“ und Cache sowie Daten zu löschen, aber ich verstehe nicht genau, was das bedeuten soll.
Es gibt ein ähnliches GUI-Tool zum Bereinigen und Anpassen eines nicht gerooteten Amazon Fire Tablets per ADB.
https://xdaforums.com/t/windows-linux-tool-fire-toolbox-v33-...
Ich frage mich, warum man nicht einfach ein vollständig sauberes Android aus dem Quellcode kompilieren und direkt auf einem Telefon installieren kann.
Was genau verhindert das?
Allerdings muss es ein Telefon sein, dessen Bootloader entsperrt werden kann, und da die Hersteller große Teile des Quellcodes nicht bereitstellen, kann man kein Image bauen, das exakt dem des Herstellers entspricht.
Wenn die Hardware unterstützt wird, kann man ein von der Community gepflegtes Betriebssystem wie LineageOS installieren.
Der Nachteil ist, dass Apps wie Google Pay dann möglicherweise nicht mehr funktionieren, weil das SafetyNet-Attestierungssystem von Google bestanden werden muss.
Es gibt zwar Umgehungen, aber die wirkten auf mich immer wie instabile Hacks.
Der Smartphone-Markt ähnelt dem Desktop-Markt der 90er Jahre.
Das heißt nicht, dass es einfach ist, aber der gesamte Quellcode ist vorhanden.
Um auf Android-Geräten vorinstallierte Apps zu entfernen, ist ADB direkt oder indirekt die einzige Wahl.
Selbst mein altes billiges 10-Zoll-Mediacom-Tablet ließ sich mit keinem Tool rooten, aber das Entfernen unnötiger Dienste und Einträge wurde mit ADB einfach.
Es ist allerdings ziemlich riskant, und inzwischen laufen Google-Dienste darauf nicht mehr, aber WhatsApp für den Kontakt mit den 7 oder 8 Personen, die ich nicht zur Nutzung von E-Mail überreden konnte, funktioniert noch, und Downloads aus F-Droid sind ebenfalls möglich, also reicht mir das.
https://shizuku.rikka.app/
https://github.com/samolego/Canta
Für die schwer verständlichen Pakete auf Android-Geräten wird nach einer aktuellen Liste gesucht, aus der hervorgeht, was jedes einzelne tatsächlich macht und welche Auswirkungen es hat, wenn man es deaktiviert oder entfernt.
Besonders wichtig sind Paketabhängigkeiten, also Fälle, in denen das Entfernen eines auf den ersten Blick irrelevanten Pakets etwas anderes kaputtmacht.
[1] - https://github.com/Universal-Debloater-Alliance/universal-an...