Datenschutzfreundliches Stock-Android mit der Android Debug Bridge ADB - für Samsung Stock-ROM und andere Plattformen

Wer Wert auf ein nicht-spionierendes Handy legt, ist mit den Android Custom ROMs, die in Mikes kürzlich durchgeführter Analyse gut abschnitten, sicher am besten bedient:
https://www.kuketz-blog.de/android-grapheneos-calyxos-und-co-unter-der-lupe-custom-roms-teil1/

Allerdings ist dieser Weg nicht immer praktikabel. Diese Custom ROMs sind nur für wenige Android Smartphones verfügbar. Im wesentlichen sind dies die Google Pixel, das Fairphone und wenige ältere Geräte anderer Hersteller. Für die meisten Android Smartphones gibt es entweder gar kein Custom ROM oder nur ein unsicheres, bei dem z.B. der Bootloader nach der Installation nicht mehr geschlossen werden kann oder Sicherheitsupdates nicht automatisch eingespielt werden. Darüber hinaus läuft Android auf vielen weiteren Gerätetypen, wie Tablets und Smart-TVs für die fast immer nur das installierte Stock-ROM des Herstellers verfügbar ist.

Ich wollte daher hier zeigen, wie mit Hilfe der Android Debug Bridge (ADB) und weniger Apps zur Geräteadministration auch ein vorinstalliertes Stock-ROM mehr oder weniger datenschutzfreundlich umgebaut werden kann. Im Idealfall kann fast das Datenschutzniveau eines guten Custom ROMs erreicht werden. Diesen Idealfall habe ich bei einem Samsung Tablet vom Typ SM-T225 mit SIM-Karte unter Android 14 verwirklicht. Daher wollte ich im folgenden den Ansatz an Hand dieses Geräts demonstrieren. Das Vorgehen lässt sich direkt auf andere aktuelle Samsung Smartphones und Tablets übertragen, auf denen dasselbe Android Stock-ROM von Samsung läuft. Am Ende gehe ich auf wenige Geräte weiterer Hersteller ein, bei denen ich diesen Ansatz auch verfolgt hatte, mal mit mehr, mal mit weniger Erfolg.

Das Vorgehen ist relativ einfach: Unter Einstellungen / Verbindungen / Datennutzung und mit einer installierten Firewall wie RethinkDNS wird das Datensendeverhalten der vorinstallierten (System-) Apps von Google und des Geräteherstellers, in diesem Fall also Samsung beobachtet. Apps die „nach Hause funken“ werden darauf geprüft, ob sie essentiell sind oder deaktiviert, deinstalliert werden können. Nicht deinstalliert werden sollen Apps, die für System- und Sicherheitsupdates sorgen. Alles andere steht grundsätzlich zur Disposition. Mit Hilfe von veröffentlichten Bloatlisten wird vor der Deinstallation abgeglichen, ob damit ein Risiko verbunden ist, also ob andere Nutzer eine App bereits ohne negative Nebenwirkungen deinstallieren konnten. Da bei Systemapps meistens die Deinstallation und selbst die Deaktivierung unter Einstellungen blockiert ist, wird die ADB benötigt. Mit dieser lässt sich diese Sperre umgehen und praktisch alle vorinstallierten Apps lassen sich entweder Deaktivieren oder Deinstallieren. Dafür sind keine Root-Rechte notwendig, die hier auch nicht verwendet werden sollen. Das Ziel ist, die Sicherheitsarchitektur in Form des Rechte- und Zugriffsmanagements und der Sicherheits- und Systemupdates nicht anzutasten. Die ADB ist darüber hinaus ein mächtiges Debug-Tool um weitere Optimierungen am System vorzunehmen.

Der Ansatz ist nicht völlig ohne Risiko. Mit der ADB können auch essentielle Systemapps deinstalliert werden, wie z.B. der Launcher. Im schlimmsten Fall wird ein System „gebrickt“, also unbenutzbar gemacht. Allerdings lassen sich mit der ADB vorgenommenen Änderungen am System durch Zurücksetzen auf Werkseinstellungen rückgängig machen. Die ADB deinstalliert Systemapps nicht vollständig. Sie bleiben im Installationspackage des Betriebssystems erhalten und werden nur für das aktuelle Nutzerkonto deinstalliert, deakiviert. Ein System lässt sich allerdings soweit zerschießen, dass das Menü zum Zurücksetzen in den Einstellungen nicht mehr erreicht werden kann. Daher empfehle ich sich ZUERST mit dem Recovery-Menü vertraut zu machen. Dieses lässt sich meistens mit den Tasten am Rand des Smartphones (z.B. Funktionstaste + eine Lautstärketaste) beim Boot des Geräts erreichen und ermöglicht ein Zurücksetzen auf Werkseinstellungen auch wenn Android nicht mehr startet. Die Tastenkombinationen variieren je nach Hersteller und lassen sich im Internet recherchieren oder stehen in der Gebrauchsanleitung. Mit umsichtigem Vorgehen habe ich es bisher vermieden, ein Androidgerät mit der ADB so zu zerschießen, dass ich es zurücksetzen musste, obwohl ich den Ansatz bereits bei ca. einem halben Dutzend Geräten verschiedener Hersteller verfolgt habe. In jedem Fall ist eine Datensicherung vor der Arbeit mit der ADB vorzunehmen, da falls ein Zurücksetzen auf Werkseinstellungen notwendig ist, auch alle Nutzerdaten gelöscht werden. Ich will außerdem klarstellen, dass ich keine Verantwortung übernehme, wenn jemand diesen Blogbeitrag liest und daraufhin sein Gerät zerschießt! Leser handeln auf eigene Verantwortung!

Nachdem das Gerät von den „nach Hause funkenden“ Apps bereinigt wurde, empfehle ich einige weitere Einstellungen zu ändern, die ebenfalls nur mit der ADB oder speziellen Apps zur Administration und nicht mit den regulären Einstellungen zugänglich sind. Zudem müssen die deinstallierten Nutzerapps von Google und Handyhersteller, wie z.B. der Browser durch datenschutzfreundliche Alternativen ersetzt werden. Wenn auf die Googledienste und spionierende Nutzerapps, wie z.B. Whatsapp nicht verzichtet werden kann, lassen sich diese in einem Arbeitsprofil oder zweitem Nutzerprofil isolieren, so dass zumindest das Hauptnutzerkonto sauber bleiben kann.

  1. Installation von ADB und Apps zur Administration

Zuerst wird die ADB benötigt. Sie wird auf einem PC installiert. Das Androidgerät kann damit über ein USB DATEN-kabel oder WLAN (nützlich z.B. für Android TV) gesteuert, programmiert werden. Hier Links auf Beschreibungen zur Installation, Nutzung und zu den Befehlen:

https://www.giga.de/apps/android/tipps/adb-installieren-die-android-debug-bridge-zum-laufen-bringen/
https://developer.android.com/tools/adb?hl=de

Um die ADB nutzen zu können, müssen auf dem Androidgerät die Entwickleroptionen und USB- bzw. Wifi-Debugging freigeschaltet werden. Meist funktioniert die Freischaltung, indem unter Einstellungen / Softwareinformationen ca. 7-mal auf die Buildnummer getippt wird. Falls das für ein Gerät nicht funktioniert, hilft eine Internetrecherche.

Auf dem zu reinigenden Androidgerät sind neben der ADB die folgenden Apps notwendig oder zu empfehlen (teilweise gibt es Alternativen):

a. F-Droid Appstore, herunterzuladen von f-droid.org, Berechtigung zur Installation von Apps erteilen

b. Von F-Droid wird installiert:
RethinkDNS zur Überwachung des Datenverkehrs (alternativ Blokada von deren Webseite)
Package Manager zur Administration der Apps auf dem Gerät
Captive Portal Controller zur Administration der Verbindungschecks für WLAN-Netze
Shelter oder Insular zum Einrichten eines Arbeitsprofils
Aurora Store zum „pseudo-anonymen“ Zugriff auf den Google Playstore ohne eigenes Googlekonto

c. Von Aurora wird installiert:
Permission Pilot zur Administration von App-Berechtigungen

d. Alternative, datenschutzfreundliche Nutzerapps
Da die nach Hause funkenden Apps von Google und Handyhersteller ersetzt werden sollen, können auch gleich alternative, datenschutzfreundliche Apps aus F-Droid, teilweise auch Aurora installiert werden. Hier eine subjektive Auswahl:
Browser und Suchleiste: Fennec-, Tor Browser; Tastatur: AnySoftKeyboard inkl. deutsche Tastatur; SMS: Simple Mobile Tools; Start-App/Launcher: ADW-Launcher aus Aurora; File Manager: Amaze oder Simple Mobile Tools; Uhr: Simple Mobile Tools; Mail: K-9, Karten: Osmand; Videos & Musik: NewPipe; Medienplayer: VLC; Galerie: Simple Mobile Tools; Wetter inkl. Widget: Kleine Wettervorschau
Unter Einstellungen / Apps / Standard Apps werden nun anstatt der vorinstallierten Apps der Fennec Browser, die Simple Mobile SMS App, der ADW-Launcher und das AnySoftKeyboard eingetragen oder was der Nutzer sonst bevorzugt. Die Einstellung der Standardtastatur findet sich je nach Gerät in einem anderen Menü, z.B. unter „Allgemeine Verwaltung“. Falls die Dialer / Telefonapp von Google installiert ist, sollte auch diese ersetzt werden, da der Google-Dialer die Anrufliste regelmäßig an Google sendet. Bei alternativen Dialerapps zuerst prüfen, ob sie auf dem Gerät funktionieren.

  1. Deinstallation der vorinstallierten „funkenden“ Apps

Voraussetzung für diesen Schritt ist, dass die ADB installiert ist und Zugriff auf das Androidgerät hat (USB Debugging aktiviert). Die ADB „kennt“ Apps unter einem anderen Namen, als dem in den Einstellungen sichtbaren. Der Google Play Store z.B. wird von der ADB als „com.android.vending“ erkannt. Daher verschaffen wir uns mit dem Befehl „adb shell pm list packages“ eine Liste der Namen aller installierten Apps und kopieren diese am besten aus der Befehlszeile in eine separate Datei. Zum Übersetzen der Appnamen hilft z.B. die App Package Manager. Dessen Suchfunktion findet Apps unter allen Namen, die sie hat.

Nun schauen wir unter Einstellungen / Datennutzung oder nach dessen Aktivierung unter Rethink-DNS nach, welche Apps Daten versenden und deaktivieren, deinstallieren diese. Deaktivieren / wieder aktivieren geht unter ADB mit diesen beiden Befehlen:

adb shell pm disable-user <PACKAGE_NAME>
adb shell pm enable <PACKAGE_NAME>

<PACKAGE_NAME> ist der Name der App in der mit ADB erzeugten Appliste, also z.B. com.android.vending. Diese Befehle funktionieren in vielen Fällen selbst dann, wenn unter Einstellungen / Apps „Deaktivieren“ ausgegraut, also blockiert ist.

Deinstalliert werden Apps mit diesem Befehl:
adb shell pm uninstall -k <PACKAGE_NAME>

Diesen Befehl nie ohne den Zusatz „-k“ ausführen, da sonst das Apppaket komplett entfernt wird. „-k“ schränkt die Deinstallation auf das Nutzerkonto ein. Somit kann die App mit diesem Befehl ohne Appstore und APK-Datei wieder installiert werden, falls nach einer Deinstallation Probleme auftreten oder doch nützliche Funktionen verschwinden:
adb shell pm install-existing <PACKAGE_NAME>

Es ist eine Ermessensfrage, ob Apps nur deaktiviert oder gleich deinstalliert werden. Das Versenden von Daten ist nach meiner Erfahrung in beiden Fällen unterbunden. Deaktivieren per ADB kann in manchen Fällen blockiert sein, Deinstallieren funktioniert fast immer. Deaktivieren ist weniger riskant, da es immer rückgängig gemacht werden kann. Der Befehl „install-existing“ bringt dagegen in sehr wenigen Fällen eine App nicht zurück. Falls sie dennoch essentiell war, bleibt nur noch das Zurücksetzen auf Werkseinstellungen. Ich empfehle Deinstallieren nur, wenn eine Systemapp in mehr als einer Bloatliste als problemlos zu entfernen gelistet ist. Ein vorsichtiger Ansatz wäre, Apps wenn möglich zuerst nur zu Deaktivieren und erst wenn es damit keine Probleme gibt, zu deinstallieren. Weiter helfen auch die Bezeichnungen der Apps und gesunder Menschenverstand. Die Systemapp „com.google.android.permissioncontroller“ würde ich nicht deinstallieren, da das Berechtigungsmanagement essentiell ist, die Systemapp „com.google.android.syncadapters.contacts“ dagegen schon, da ich meine Kontakte nicht mit der Google-Cloud synchronisieren will.

Beim Deinstallieren von übergriffigen Systemapps kommt einem der modulare Aufbau von Android entgegen. Unter Android sind auch die Betriebssystembestandteile nur „Apps“, die weitgehend unabhängig voneinander funktionieren. Wird z.B. die App des Google Playdienstes „com.google.android.gms“ deinstalliert, verschwindet das Google-Menü aus den Einstellungen und es gibt keine Werbe-id mehr. Apps, die auf die Google Playdienste zugreifen, funktionieren nicht mehr, allen voran die diversen Googledienste (App Store, Karten, Mail, etc.). Alles andere ist davon aber unbeeinträchtigt und funktioniert weiter, inkl. dem weiter vorhandenen Rest der Einstellungen-App.

Nicht deinstalliert werden soll die App für System- und Sicherheitsupdates. Bei Samsung heißt sie aktuell „com.wssyncmldm“. Häufig tragen diese Apps oder die Domains, die sie kontaktieren das Kürzel (f)ota im Namen, das für „(firmware) over the air“ steht. Falls diese App nicht auf Anhieb zu erkennen ist, in den Einstellungen eine Updateanfrage manuell anstoßen und z.B. in RethinkDNS schauen, welche App und welche Verbindungen aktiv werden.

Die Apps und Systemapps von dritten Internetkonzernen, wie z.B. Spotify, Netflix, Facebook usw. empfehle ich unbedingt zur Deinstallation. Teilweise haben diese Konzerne Deals mit den Geräteherstellern, um vorinstallierten Apps erweiterte, invasive Berechtigungen einzuräumen, die für die Versionen im Google Playstore nicht erlaubt sind, da sie selbst die Richtlinien von Google verletzen würden.

Hier ist meine Debloatliste für Samsung veröffentlicht, erprobt am Tablet SM-T225 mit Mobilfunkmodem:
https://gist.github.com/Maetih/2718d0e0a23940d8cb0e6a9235adddd8

  1. Google Dienste

Die Gretchenfrage beim Säubern von Android ist, was mit den Google-Diensten geschehen soll. Die zusätzliche Bloatware des Herstellers, wie z.B. ein weiteres App Store und Nutzerkonto werden kaum vermisst werden. Ohne Googledienste glauben viele Nutzer allerdings nicht auskommen zu können und manche Nutzerapps funktionieren tatsächlich nicht ohne diese Dienste - die meisten überraschenderweise jedoch schon. Die Googledienste bestehen im engeren Sinn aus diesen vier Apps:

com.google.android.googlequicksearchbox Google App & Suchleiste
com.google.android.gms Google Play Dienste
com.android.vending Play Store
com.google.android.gsf Google Services Framework

Vending ist der Playstore. Im Kern bestehen die Playdienste aber aus der Google-App, die die Suchleiste erzeugt, der Systemapp Google Play Dienste (GMS), die in den Einstellungen das Google Untermenü erzeugt und der GSF App, die selbst keine sichtbare Funktion hat, ohne die die beiden anderen Apps aber nicht funktionieren. Unter Android TV heißt die Google App „com.google.android.katniss“. Solange diese drei Apps aktiv ist, wird jede Nutzung des Gerätes, jede installierte App, etc. an Google gemeldet und wenn Nutzer mit einem Konto eingeloggt sind, diesem Nutzerkonto zugeordnet (schaut in Eurem Googlekonto nach, was dort zu Geräten gelistet ist). Das ist für mich inakzeptabel. Ich habe mich daher gegen die allgemeine Nutzung der Googledienste entschieden, gehe jedoch folgenden Kompromiss ein: Mindestens die funkenden Apps Vending, GMS und die Google App sind in meinem Hauptnutzerprofil deinstalliert. Weitere Google Anwendungsapps (z.B. Chrome, Youtube, Mail) auch, da sie ohne diese Dienste nicht funktionieren oder Fehlermeldungen von sich geben. Ich habe ein Arbeitsprofil mit Shelter eingerichtet. In diesem sind alle vier Apps installiert, jedoch bin ich dort nicht mit Googlekonto registriert und zu mindestens 98% der Zeit sind alle 4 Apps „eingefroren“, erfassen und senden also keine Daten (Funktion des Arbeitsprofils, vergleichbar zu deaktivieren). Nur wenn ich im Arbeitsprofil eine App nutzen will, die die Googledienste tatsächlich benötigt (z.B. Google Translate um im Urlaub Speisekarten zu übersetzen) taue ich die Google-Dienste auf und betreibe sie ohne Nutzerkonto. Ich nutze keine App und vermisse auch keine, die ein Google Nutzerkonto voraussetzt.

  1. Arbeitsprofil und weitere Nutzerprofile

Wie beschrieben kann das Arbeitsprofil für übergriffige Apps und auch die Googledienste genutzt werden, um diese zu isolieren und ihren Zugriff auf persönliche Daten im Hauptprofil, wie Kontakte, Anruflisten, Mediendateien, Liste installierter Apps etc., zu unterbinden. Zusätzlich kann das Arbeitsprofil als Ganzes oder einzelne Apps davon eingefroren werden. Apps in diesem Zustand erfassen und senden keine Daten. Nach dem Auftauen laufen sie wie zuvor weiter. Sie verlieren durch das Einfrieren also auch keine Daten, wie z.B. Logins.
Das Arbeitsprofil ist im Stock-ROM implementiert - oder auch nicht oder nur schlampig. Apps wie Shelter oder Insular zum Einrichten des Arbeitsprofils rufen diese Funktion nur auf und machen die Einstellungen sichtbar. Ob das Arbeitsprofil funktioniert hängt daher vom Gerät, Hersteller und der Androidversion ab. Für jedes neu erzeugte Arbeits- und weitere Nutzerprofile gilt: Die im Hauptprofil deaktivierten, deinstallierten Apps und Systemapps sind dort in einer Untermenge wieder aktiv und müssen erneut per ADB deaktiviert, deinstalliert werden. Da nun mehrere Profile auf dem Gerät vorhanden sind, muss bei jedem ADB-Befehl spezifizert werden, für welches Profil er gelten soll. Der Befehl „adb shell pm list users“ zeigt die aktiven Nutzerkonten mit ihren Nummern an, der Befehl „adb shell pm get-max-users“ die maximal möglichen User. Insbesondere bei älteren Androidversionen und bei Android-TV kann die Anzahl der Profile auf eines beschränkt sein. Dann kann kein Arbeitsprofil eingerichtet werden. Wenn ein Befehl nur auf ein Nutzerkonto wirken soll, muss dessen Nummer mit dem Zusatz „–user “ eingefügt werden, wobei n die Nummer des Nutzers ist. Das Hauptprofil hat üblicherweise die Nummer 0, das Arbeitsprofil die Nummer 10. Dieser Befehl deinstalliert in diesem Fall z.B. den Google Play Store aus dem Arbeitsprofil:

adb shell pm uninstall -k --user 10 com.android.vending

Bei aktuellen Samsunggeräten sind einige der „Knox“ Apps und die App „com.samsung.android.container“ für das Arbeitsprofil notwendig. Diese daher nicht deinstallieren, obwohl sie auf manchen Debloatlisten auftauchen und zum Teil Daten versenden. Eine weitere Samsungspezialität ist, dass Arbeits- und Nutzerprofil so hermetisch getrennt sind, dass ein Dateitransfer zwischen beiden auf dem Gerät nicht möglich ist, selbst wenn diese Option in Shelter freigegeben ist. Ein Dateitransfer ist also nur über das Internet oder einen PC möglich.

  1. Verbindungschecks und Assisted-GPS

Mike hat in seiner Analyse der Custom ROMs auf den Datenverkehr von Closed Portal Verbindungschecks und Assisted-GPS hingewiesen, der teilweise sogar am VPN vorbeigeführt wird und daher in Firewall-Apps wie Rethink-DNS nicht sichtbar ist, die die VPN-Funktion nutzen. Für mein Samsunggerät habe ich den WLAN-Datenverkehr daher mit einer Fritzbox und Wireshark aufgezeichnet, nachdem ich die Systemapps, wie in meiner Bloatliste gelistet, entfernt hatte. Tatsächlich traten keine Anfragen zu SUPL- und PSDS-Servern bei eingeschaltetem GPS auf. Es treten aber Verbindungen auf zu einem Assissted-GPS Dienst namens EPO von Mediatek, dem Prozessorhersteller. Von dort wird versucht, ungefähr einmal wöchentlich eine Datei herunterzuladen. Mit den deinstallierten Systemapps habe ich also auch A-GPS in Bezug auf Anfragen bei Google entfernt (oder Google A-GPS ist bei Samsung von vornherein nicht eingerichtet). Falls ich es entfernt habe, weiß ich nicht mit welcher Systemapp Google A-GPS entfernt wurde. Verdächtig sind für mich der Google Playdienst und die App „com.google.android.gms.location.history“.
Die Closed Portal Verbindungsschecks können auch bei Stock ROMs auf andere Server, als den meist voreingestellten Google-Server umgeleitet werden. Mike hat hier die ADB Befehle dazu aufgelistet:
https://www.kuketz-blog.de/empfehlungsecke/#captive-portal

Mit der App „Captive Portal Controller“ z.B. aus F-Droid lässt sich diese Einstellung auch ändern und vor allem anzeigen.

  1. Berechtigungsmanagement

Das Berechtigungsmanagement unter Android ist leider ein tiefer, dunkler Sumpf in dem Daten unsichtbar versickern. Jedes Android kennt nicht nur die Standardberechtigungen, wie Standort, Kamera, Kontakte, etc., die in den Einstellungen angezeigt werden und teilweise vom Nutzer entzogen werden können. Jeder Entwickler kann sich für seine Apps, insbesondere für Systemapps neue Berechtigungen ausdenken und umsetzen, die nirgendwo unter Einstellungen sichtbar sind. So könnte z.B. der Entwickler einer App namens „datenkrake“ dieser eine alternative Standortberechtigung mit dem Namen „com.datenkrake_inc.datenkrake.permission.ALT_LOCATION“ geben, mit der die App auf das GPS zugreifen und Standortdaten nach Hause funken könnte, auch wenn die Standard-Standortberechtigung von Android der App nicht erteilt wurde. Tatsächlich könnte diese App in den Einstellungen so aussehen, als ob ihr überhaupt keine besonderen Berechtigungen erteilt worden wären. Solche Tricks sind vor allem bei vorinstallierten Systemapps anzutreffen, da ausgerechnet Google mit seinen Richtlinien für Apps im Playstore dort solchen Missbrauch einschränkt. Systemapps gehen an dieser Kontrolle vorbei, da sie direkt vom Gerätehersteller kommen. Wie verbreitet der Missbrauch ist und wie perfide er ausgenutzt wird, ist in diesen beiden Veröffentlichungen dokumentiert:

https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/684/An_Analysis_of_Pre-installed_Android_Software_2019_EN.pdf?sequence=1
https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/1715/Mules_and_Permission_Laundering_in_Android_Dissecting_Custom_Permissions_in_the_Wild.pdf?sequence=1

Von denselben Autoren bzw. dem Institut IMDEA wurden übrigens weitere bahnbrechende Analysen zum Thema Tracking über alle möglichen Internetanwendungen und Kanäle veröffentlicht. Die Autoren listen einige derartige, missbräuchliche Berechtigungen auf, nach denen Geräte untersucht werden können. Auf meinem Samsunggerät habe ich ein Beispiel gefunden. Samsung lieferte das Gerät mit der Systemapp „com.netflix.partner.activation“ aus, die über die Berechtigung „com.netflix.partner.activation.permission.CHANNEL_ID“ verfügt. Unter Einstellungen / Apps wird für diese App selbst mit „Alle Berechtigungen“ (auf 3 Punkte klicken) keine einzige Berechtigung angezeigt. Für den durchschnittlichen Nutzer ist sie also unsichtbar. Ich kann nur spekulieren, was es mit der Berechtigung „Channel-ID“ auf sich hat. Offensichtlich hat Netflix mit Samsung einen Deal, diese Systemapp mitzuliefern. Die App ist unauffällig und sendet keine Daten. Wahrscheinlich ist sie daher ein schlafender Trojaner, der erst aktiv wird, nachdem die eigentliche Netflix App installiert ist und der dazu dient, dieser die erweiterte Berechtigungen „Channel_ID“ weiterzugeben, da Google diese Berechtigung bei einer App im Playstore vielleicht nicht billigen würde. Die Berechtigung könnte darin bestehen, Medienkanäle außerhalb der Netflix App zu beobachten, also z.B. welche Streams ein Nutzer bei Disney+ schaut. An solchen Daten hätte Netflix sicher Interesse.

Um derartigen Missbrauch abzuschalten, ist es zuerst notwendig, solche Berechtigungen zu erkennen. Die App „Package Manager“ zeigt alle Berechtigungen einer App an, also z.B. auch die „Channel-ID“ Berechtigung der Netflix App. Noch besser ist die App „Permission Pilot“ aus dem Playstore. Mit ihr kann das ganze System nach Berechtigungen durchsucht werden. Als Stichwörter für die Suche können die üblichen Verdächtigen verwendet werden: Facebook, Amazon, Spotify, Netflix, MSC bzw. Microsoft, plus Handy- und SoC-Hersteller Samsung, LG, Lenovo, Sony, Qualcomm, Mediatek etc., bei Chinahandys auch QQ, Tencent, Mi bzw. Xiaomi, Huawei, Oppo, HTC etc. plus Telekomfirmen Vodafone, Telecom etc. Werden unerklärliche Berechtigungen gefunden gibt es zwei Möglichkeiten: Die betreffende App per ADB deinstallieren oder der App die Berechtigung entziehen. Dies ist per ADB auch für Custom-Permissions möglich. Der folgende Befehl würde der Netflix App die „Channel_ID“ Berechtigung nehmen:

adb shell pm revoke com.netflix.partner.activation com.netflix.partner.activation.permission.CHANNEL_ID

Die Berechtigung muss im Befehl am Ende so eingegeben werden, wie sie im Package Manager oder Permission Pilot angezeigt wird. „grant“ anstatt von „revoke“ gibt die Berechtigung zurück.

Unter Android gibt es eine Art Super-Berechtigung, die auf dieselbe Art kontrolliert werden sollte. Auch sie ist unter Einstellungen unsichtbar. Sie heißt „android.permission.READ_LOGS“. Android verfügt über eine Logdatei, in der vom ganzen System Daten eingesammelt werden, darunter auch sensible wie nutzerspezifische Ids, Standortdaten, usw. Wer diese Datei selbst durchschauen will, kann sie mit dem ADB-Befehl „logcat“ extrahieren. „adb logcat --help“ zeigt die Optionen an. Apps mit „READ_LOGS“ Berechtigung können sich an diesen Daten nach belieben bedienen. Daher sollte sie allen verdächtigen (System-) Apps entzogen werden, mit diesem ADB-Befehl:

adb shell pm revoke <PACKAGE_NAME> android.permission.READ_LOGS

Ob der Entzug von Berechtigungen funktioniert hat, kann im Package Manager oder Permission Pilot kontrolliert werden. Bei der entsprechenden App muss unter Berechtigungen das Häkchen bei der entzogenen Berechtigung entfernt sein. Ich kann hier das Thema Berechtigungen leider nur streifen. Permission Pilot zeigt für mein Samsunggerät ca. 900 Custom-Permissions alleine von Samsung an!

  1. Ergebnis

Nach den beschriebenen Änderungen und Deinstallationen sind im Zeitraum einer Woche für das Samsunggerät noch die folgenden, von Systemapps ausgehenden Verbindungen zu verzeichnen (ohne Closed Portal Verbindungsschecks):

Samsung System- und Sicherheitsupdates:
*.ospserver.net

Andere Verbindungen zu Samsung (zum Teil Tracking):
dc.dqa.samsung.com
poll.gras.samsungdm.com
dir-apis.samsungdm.com
gos-api.gos-gsp.io
euprod-knoxpp.samsungknox.com

Google (Updates, Zeitserver):
play.google.com
update.googleapis.com
clientservices.googleapis.com
time.android.com

Mediatek (EPO assisted GPS)
sfepodownload.mediatek.com
sgepodownload.mediatek.com

Zeitserver
*.pool.ntp.org

Diese Verbindungen treten mit niedriger Frequenz auf, manche im Abstand von Stunden, andere im Abstand von Tagen. An manchen Tagen wird nur ein Zeitserver kontaktiert. Das übertragene Datenvolumen und die Möglichkeit zum Tracking sind somit gering. Sie gehen von Systemapps aus, die essentiell sind, wie z.B. Webview. Die meisten davon sind für wichtige oder zumindest nützliche Funktionen, wie Updates, Zeitsynchronisation, GPS. Da es sich nur um wenige Verbindungen handelt, lassen sie sich auf Wunsch gezielt mit einer Firewall, wie RethinkDNS blockieren. Tatsächlich mache ich das nur bei den Verbindungen zu Samsung, die nicht an den Updateserver gehen. Kritischere Nutzer können weitere Verbindungen, wie die zu Google oder Mediatek auf diese Weise blockieren.

Insbesondere wenn einige der wenigen verbleibenden Verbindungen mit einer Firewall wie RethinkDNS blockiert werden, ist mit den beschriebenen Maßnahmen ein Datenschutzniveau irgendwo zwischen CustomROMs wie /e/ und CalyxOS beim aktuellen Samsung Stock-ROM zu erreichen. In jedem Fall ist das an Tracker übertragene Datenvolumen gegenüber einem unveränderten Android StockROM oder auch im Vergleich zum iPhone um Größenordnungen reduziert. Systemupdates werden dennoch pünktlich eingespielt. Ich hatte das System ursprünglich unter Android 12 eingerichtet, habe Android 13 und 14 als Updates stabil eingespielt bekommen und musste an der Einrichtung, installierten und deinstallierten Systemapps mit den Updates kaum etwas ändern. Deinstallierte, deaktivierte Systemapps bleiben nach einem Update in diesem Status. Ich habe zwei Apps entfernt, die erst mit Updates reinkamen. Eine erneute Kontrolle des Datensendeverhaltens ist dennoch nach jedem größeren Update angeraten, da bei einem kommerziellen Anbieter immer damit gerechnet werden muss, dass neue Trackingfeatures eingeführt werden.

Ich rate dennoch weiterhin zu guten Custom-ROMs als erste Wahl für ein datenschutzfreundliches Gerät, einfach weil es deutlich weniger Arbeit und vor allem weniger Kontrolle erfordert, einmalig ein Custom-ROM aufzuspielen, als ein Stock-ROM wie beschrieben zu säubern und sauber zu halten.

  1. Weitere Geräte bei denen der Ansatz erprobt wurde

Erstmalig hatte ich den beschriebenen Ansatz bei einem Asus ZenPad P024 unter Android 6 schon vor Jahren erprobt, mit ähnlich gutem Erfolg wie beim Samsung Tablet. Der Datenfluss zu Google und Asus ließ sich fast vollständig unterbinden. Asusgeräte sind aber nun schon länger nicht mehr aktuell. Relevanter sind meine Erfahrungen mit den folgenden Geräten:

a. Google Pixel 4a und 6a
Bei Google Pixelgeräten funktioniert der Ansatz mit dem StockROM Datenschutz zu erreichen gar nicht, da auch Systemupdates über die Google Play Dienste eingespielt werden. Werden sie entfernt lässt sich das System nicht mehr aktualisieren. Nach dem Entfernen der Play-Services App geben die Geräte außerdem im Sekundentakt Warnmeldungen und -töne von sich. Google will nicht ent-Googelt werden! Der Ansatz ist bei Pixelgeräten aber auch sinnlos, da für diese alle guten Custom-ROMs verfügbar und einfach zu installieren sind.

b. Xiaomi Redmi Note 10S
Datenschutz und Chinahandys schließen sich aus! Leider findet man gerade in Kinderhänden viele Smartphones aus China, da sie am billigsten sind, so auch in meinem Bekanntenkreis. Verdienen Kinder keine Privatspäre? Ich habe daher versucht bei einem Redmi Note 10S mit Android 12 aus dem Hause Xiaomi den Datenabfluss soweit wie möglich zu reduzieren. Das gelang nicht so gut, wie beim aktuellen Samsung Stock-ROM. Xiaomi hat seine Dienste tiefer in den Android Source Code eingebaut als Samsung, damit lassen sie sich nicht im selben Umfang entfernen, ohne grundlegende Funktionen des OS zu beschädigen. Es bleibt ein signifikanter Datenfluss an Xiaomi nach China bestehen, der nur mit einer Firewall blockiert werden kann. Immerhin lässt sich das Datenvolumen an Xiaomi signifikant reduzieren und viel lästige Bloatware entfernen. System- und Sicherheitsupdates funktionieren weiterhin problemlos. Debloatlisten für Xiaomi mit mehreren Updates, davon auch eines von mir, gibt es unter folgendem Link. Apps, die nicht entfernt werden sollten, sind mit aufgeführt. Hier besteht nicht das Ziel, die Googledienste vollständig zu entfernen:
https://gist.github.com/mcxiaoke/ade05718f590bcd574b807c4706a00b1

Soweit mein Exkurs durch die ADB und verschiedene Android-Plattformen. Android Stock ROMs und auch das iOS übertragen, so wie die Systeme ausgeliefert werden, im Minutenabstand Daten an Google, Apple und im Fall von Android den Gerätehersteller, also typischerweise einige 100 bis 1000 Datensätze pro Tag. Mit den beschriebenen Methoden lässt sich das für Android Stock ROMs im Idealfall um den Faktor 100 auf wenige, einstellige Datenverbindungen pro Tag reduzieren, die vom System ausgehen. Einige vorinstallierte Systemapps müssen sogar als Malware bezeichnet werden (siehe z.B. Netflix Partner Activation), installiert um Schutzmechanismen des Betriebssystems zu umgehen. Es stellt daher ein größeres Risiko in Bezug auf Sicherheit und Persönlichkeitsschutz dar, ein Androidgerät im Auslieferungszustand zu betreiben, als es mit den beschriebenen Methoden aufzuräumen. Ich würde mich freuen, wenn weitere Anwender die Fremdbestimmung ihrer Androidgeräten außer Kraft setzen und wie beschrieben, selbst von ihren Geräten Besitz ergreifen würden.

5 „Gefällt mir“

Bei dem Punkt kann der UniversalAndroidDebloater einiges erleichtern.
Ist zwar auch nicht für alle Geräte verfügbar, aber doch für ziemlich viele:

Hier gibt es auch eine (unterhaltsame) Anleitung dazu von ct3003: Vorinstallierte Schrott-Apps löschen mit Universal Android Debloater

2 „Gefällt mir“

Noch ein Tool: ADB AppControl, ungetestet. Im A-H-Forum gibt es einen Thread zum Programm

Vielen Dank für die schnelle Resonanz. Hier sind als Nachtrag Erfahrungen mit zwei weiteren Androidvarianten, die im Hauptbeitrag wegen der Zeichenbeschränkung keinen Platz fanden:

a. Android TV auf Nvidia Shield
Ich verbinde kein Fernsehgerät direkt mit dem Internet, da in diesem Fall auch lineares Fernsehen und am Ende jeder Druck auf die Fernbedienung getrackt wird. Internetzugriff und Streamingdienste sind auf eine separate Box beschränkt, in diesem Fall eine Nvidia Shield auf der Android TV V.11 läuft. Android TV ist mit tendenziell noch mehr Werbung und nach Hause funkender Bloatware gefüllt, als Stock-ROMs von Mobilgeräten. Der Ansatz diese Bloatware zu entfernen, wenn nötig mit der ADB ist daher auch für diese Plattform zu empfehlen. Das Vorgehen ist analog zu dem für Smartphones, Tablets beschriebenen, bis auf wenige Besonderheiten von Android TV. Diese sind:

  • Um kein USB-Kabel zwischen Fernseher und PC spannen zu müssen, ist es zu empfehlen, WiFi-Debugging als ADB-Schnittstelle zu nutzen. Anleitungen dazu und zur Aktivierung der Entwickleroptionen gibt es im Internet. Über die ADB funktioniert das Sideloading von Apps als APK-Dateien.
  • Der F-Droid App Store lässt sich auf der Nvidia Shield auch unter Android TV installieren. Dort gibt es einige FOSS-Apps, die unter Android TV sehr nützlich sind und gut funktionieren, obwohl es sich nicht um spezielle TV Varianten für eine Bedienung ohne Touchscreen handelt: Fennec Browser (häufig bringt Android TV keinen Browser mit), VLC Player, Kodi Medienplayer, Amaze Filemanager, NewPipe, eine Galerie App, Zapp zum Zugriff auf alle Mediatheken der öffentlich-rechtlichen Sender. Der Package Manager kann zur Administration von Apps verwendet werden. Um Werbung auf dem Homescreen zu unterbinden, empfehle ich einen alternativen TV Launcher, z.B. den FLauncher (Playstore).
  • Android TV stellt grundsätzlich mehrere Nutzerprofile zur Verfügung, aber kein Arbeitsprofil, das für Firmenanwendungen entwickelt wurde (MDM), welche Google nicht im Fernseher sieht. Bei der Nvidia Shield ließen sich weitere Profile jedoch nicht aus den Einstellungen, sondern nur per ADB aktivieren, bzw. löschen mit „adb shell pm create-user (remove-user) “. Damit ist die Methode, kritische Apps in weitere Nutzerprofile zu verlagern wenig praktikabel.
  • Die Google App heißt unter Android TV wie gesagt „com.google.android.katniss“. Die Funktion ist ähnlich. Solange sie und die Play Dienste App aktiv sind, wird das Nutzerverhalten durch Google getrackt und dem Googlekonto zugeordnet. Da ich nur ein Nutzerprofil verwende, habe ich die Google-Dienste dort nicht deinstalliert, sondern deaktiviert. Falls sie doch benötigt werden, können sie kurzzeitig aktiviert werden.
  • Der Aurora Store funktioniert inzwischen. Ältere Versionen liefen nicht. Das Problem ist jedoch, dass Aurora und Racoon als alternative App-Quellen schlecht nach Android-TV spezifischen Appversionen filtern können. In manchen Fällen werden diese benötigt, in anderen laufen auch die Versionen für mobile Geräte. Immerhin kann der Aurora Store zum App-Update genutzt werden. Weitere alternative Quellen für spezifische Android TV Apps sind Plattformen wie APK-Mirror. Der Google Playstore kann daher unter Android TV stärker vermisst werden, als auf mobilen Geräten.
  • RethinkDNS läuft auf meiner NvidiaShield im Prinzip, die automatische Aktivierung nach einem Neustart funktioniert jedoch nicht. Daher benutze ich zum Filtern noch ein altes Blokada V.4, das diese Einschränkung nicht hat.
  • Die App für Systemupdates heißt bei der Nvidia Shield „com.nvidia.ota“, die Server für Updates werden unter den Domains „ota.nvidia.com“ und „ota-internal.nvidia.com“ kontaktiert.
    Unter Beachtung dieser Einschränkungen funktioniert der datenschutzfreundliche Umbau der Nvidia Shield ähnlich gut, wie beim Samsungerät. Die Nvidia Shield eignet sich nicht nur zum Streamen von Medien, sondern auch zum Gaming. Welche Systemapps deaktiviert werden können, hängt daher stark vom Nutzungsverhalten ab. Wer Gaming nutzen will, mus mehr Datenverkehr zu Nvidia zulassen. Bloatlisten sind daher sehr subjektiv und ich veröffentliche meine aus diesem Grund nicht.

b. Tolino Shine 3 Ebook Reader
Der Tolino besteht aus einem Unterbau aus Android 4 auf dem im Kioskmodus die Tolino-App „de.telekom.epub“ läuft. Alle für den Nutzer zugänglichen Funktionen, inkl. der Systemupdates und der Browser sind in diese App integriert. Mit Hilfe von Fastboot und der ADB es mit dieser Anleitung dennoch möglich, die Android-Oberfläche zu erreichen oder das Gerät zu Rooten:
https://allesebook.de/anleitung/tolino-shine-3-adb-root-und-eigene-apps-installieren-video-978782/

Ich habe diesen Hack ohne permanenten Root durchgeführt, so dass ich den Reader am Ende wieder in den Ausgangszustand zurücksetzen konnte, um zu prüfen, welche alternativen Apps sich installieren lassen und ob sich der Datenfluss des Gerätes kontrollieren lässt. Zuvor hatte ich den Datenverkehr an der Fritzbox aufgezeichnet. Der Tolino kontaktiert neben Zeitservern im wesentlichen die folgenden Domains, solange er nur zum Herunterladen von Ebooks bei Thalia mit Nutzerkonto und zum Lesen dieser Bücher genutzt wird:

clients3.google.com
*.pageplace.de
mytolino.com
*.thalia.de

Weshalb „clients3.google.com“ kontaktiert wird ist mir nicht klar, da das Android des Gerätes tatsächlich Google-frei ist! Es sind keine Google-Systemapps installiert. „pageplace.de“ ist die Domain des App- und Geräteentwicklers Kobo Rakuten und sie läuft nicht auf einem deutschen, sondern einem US-Server. „mytolino.com“ und „thalia.de“ stellen den Ebook Shop und die Inhalte bereit. Sobald jedoch der Browser gestartet wird, ist Google richtig im Boot. Es werden Domains wie „google-analytics.com“ und „adservice.google.de“ kontaktiert! Es findet also Tracking statt. Auf jeden Fall im Browser, der für die Nutzung der Funktion „Onleihe“ nötig ist. Die Tolino-Allianz, Kobo und Thalia können im Prinzip das Leseverhalten tracken. Bis zu welchem Grad sie das machen, kann ich nicht sagen, da ich den Datenverkehr nicht entschlüsselt habe.

Ich konnte den Tolino per ADB ansteuern, den F-Droid Store installieren und aus dem F-Droid Store Apps installieren, die noch für Android 4 geschrieben sind, wie den PrivacyBrowser, den TotalCommander und die VPN-Firewall Apps PersonalDNSFilter, tPacketCapture (Playstore). Allerdings waren die Firewall Apps nicht in der Lage, den Datenverkehr zu filtern. Der Grund dürfte sein, dass das rudimentäre Android 4 des Tolino keine VPN-Funktion bereitstellt. Damit ist Datenfilterung im Gerät nicht möglich. Bloatware ist auch keine vorhanden, die entfernt werden könnte, da alle Nutzerfunktionen in der einen Tolino-App konzentriert sind.

Was bleibt, ist eine alternative Ebook-App zu installieren. In F-Droid gibt es den KOReader. Er funktioniert und damit wird der Tolino zum Open-Source Reader, wenn die Tolino App entfernt wird. Das wäre, wenn überhaupt aber nur mit vollen Rootrechten möglich gewesen. Da Eink-Displays zudem spezielle Graphiktreiber benötigen, sehen die Seiten mit einer alternativen Ebook App schlechter aus. Weiterhin können alternative Apps Ebooks mit DRM nicht unbedingt öffnen. System- und Sicherheitsupdates hätten auch keine mehr eingespielt werden können.

Die Möglichkeiten am Tolino sind also beschränkt. Wer ihn datenschutzfreundlich betreiben will, tut sich leichter, ihn einfach Offline zu nutzen und die Ebooks per USB aufzuspielen. Mit dem veralteten, unsicheren Android 4 Unterbau sollten ohnehin keine Verbindungen zu nicht vertrauenswürdigen WLAN-Netzen und Webseiten aufgebaut werden.

2 „Gefällt mir“

Vielen Dank für den Artikel!

Falsch!!

  1. Die Option „-k“ bedeutet laut „pm --help“ folgendes:

„-k: keep the data and cache directories around after package removal.“

=> Da man beabsichtigt, selbstverständlich auch die Appdaten einer App zu löschen, die man deinstallieren will, sollte die Option „-k“ also NICHT verwendet werden!

  1. Daher ist es auch völlig falsch zu behaupten, diese Option würde die Deinstallation auf ein Nutzerkonto beschränken!
    Dazu ist die Option „–user [ID]“ gedacht.

Der KORREKTE Befehl lautet also (und so steht es auch überall im Netz!!!):

adb shell pm uninstall --user 0 PACKAGE

Dieser Teil der Anleitung ist sehr schlecht recherchiert!

Danke für die Korrektur! Meine Anleitung war an dieser Stelle tatsächlich fehlerhaft. Ich wundere mich allerdings über den Ton, den ich als unfreundlich empfinde. Ich dachte, auf diesem Forum geht es nicht zuletzt darum, Erfahrungen zu tauschen und voneinander zu lernen und nicht darum, Anlässe zu finden, sich gegenseitig „in die Pfanne zu hauen“.

Der Fehler lag daran, dass in der Vergangenheit tatsächlich die meisten Quellen empfahlen, den Befehl „uninstall“ nur mit dem Zusatz „-k“ auszuführen. Als Beispiele hier die usprünglichen Samsung-Debloatlisten, die ich nutzte:
https://www.alliancex.org/shield/apps.html
https://gist.github.com/baszoetekouw/550e6e47edf9663e52ad7648c7eab83b
https://www.reddit.com/r/GalaxyNote20/comments/imf7so/what_bloatware_did_you_disable/

Ich hatte zusätzlich mindestens eine Quelle gelesen, die ausdrücklich davor warnte, das „-k“ wegzulassen. Obwohl ich auch adb --help lesen kann, habe ich im Sinne einer Risikominimierung für Leser daher das „-k“ empfohlen. Scheinbar herrschte in der Community Konfusion, ob „-k“ den Appspeicher oder den Speicher in der die App/APK abgelegt ist, sichert.

Ich habe die Befehle nun mit allen Optionen für -k und --user durchgetestet:

Daten (kB) / Cache (kB)
385 / 127
pm uninstall -k --user 0 com.samsung.android.calendar
pm install-existing com.samsung.android.calendar
385 / 127
pm uninstall --user 0 com.samsung.android.calendar
pm install-existing com.samsung.android.calendar
0 / 0

„-k“ sichert also wie unter adb --help beschrieben nur Speicher und Cache der App, der ansonsten gelöscht wird. Die Verwendung macht nur Sinn, wenn die App wieder installiert werden soll.

Und zu „-- user <0>“
foster:/ $ pm uninstall com.google.android.syncadapters.calendar
Failure [DELETE_FAILED_INTERNAL_ERROR]

foster:/ $ pm uninstall --user 0 com.google.android.syncadapters.calendar
Success

foster:/ $ pm install-existing com.google.android.syncadapters.calendar
Package com.google.android.syncadapters.calendar installed for user: 0

Der Befehl „uninstall“ kann nur mit dem Zusatz „–user “ verwendet werden, ansonsten gibt es eine Fehlermeldung, auch auf Systemen mit nur einem Nutzerkonto.
Der Befehl „install-existing“ kann dagegen ohne den Zusatz verwendet werden. In dem Fall wird die App in das Hauptnutzerkonto installiert.

Die gute Nachricht: Der befürchtete Fall, dass eine App mit „install-existing“ nicht wieder installiert werden kann, tritt für keine der Varianten auf.

4 „Gefällt mir“

Ich erwarte, dass man die genannten (sensiblen) Befehle min. selbst ausprobiert und auf Richtigkeit geprüft wurden, wenn man Anleitungen veröffentlicht.

1 „Gefällt mir“

Errare humanum est! besagt ein Sprichwort. Wir alle machen hier und da mal einen Fehler. Und dieser kann auch bei einer Anleitung passieren.

Da hast du vollkommen recht: In die Pfanne hauen tut man bspw. ein Ei, aber keinen Menschen :wink: Die Kommunikation ist oftmals mit gewissen Schwierigkeiten verbunden, sodass Aussagen leicht missverstanden werden können. Eine Botschaft kann vom Gegenüber anders wahrgenommen werden als vom Sender gedacht. Ich empfehle dazu sich den Artikel über das Vier-Seiten-Modell durchzulesen.

Im Bewusstsein dessen sollte man stets versuchen, eine angemessene Ausdrucksweise, wozu besonders im Schriftlichen die richtige Verwendung von Satzzeichen gehört, zu finden. Oftmals ist es besser, einen vollständigen Satz zu bilden um etwaige Missverständnisse zu vermeiden.

3 „Gefällt mir“

@Maetih
Danke für die Arbeit und Mühe, die du hier aufgewendet hast.

Ich habe deinen Guide nicht im Detail durchgelesen, da ich schon vor Längerem zu der gleichen Erkenntnis wie die Entwickler verschiedener Custom-OSe kam: Änderungen via ADB sind besser als nichts, aber weit vom Datenschutz eines guten Custom-OS wie GrapheneOS entfernt (und /e/OS zählt definitiv nicht dazu).

SkewedZeppelin (DivestOS-Entwickler):

Removing apps with ADB is putting your head in the sand when you still have a bunch of daemons running in the background.
If it is your only option, then fine, but it overlooks a lot.

Also irgendwas stimmt hier doch offensichtlich nicht. Mir geht es nicht darum, den Troll zu spielen. Aber ich persönlich bezweifle sehr stark die Aussagen in dieser Anleitung und möchte verhindern, dass andere User ihr System zerschiessen und wichtige Daten verlieren.

Mit welchen Befehlen wurde dieser Idealfall denn verwirklicht? Du hast ja selber erst nach Veröffentlichung deiner Anleitung herausgefunden, dass deine Befehle zur Deinstallation - so wie sie im ersten Post stehen - gar nicht funktionieren.

Hinzu kommt, dass es für das SM-T225 keine Stock ROM basierend auf A14 gibt. Die letzte Stock ROM für dieses Modell ist 2021 erschienen und war A11. Daher verstehe ich diese Aussage ebenfalls nicht:

Mit welchem Gerät und welcher ROM wurden nun welche Befehle getestet?

Die meisten Antworten auf diese Fragen stehen bereits in meinem ursprünglichen Beitrag oder den bereits geführten Diskussionen.

Wie bereits gesagt mit dem Befehl z.B. aus dieser Debloatliste:

adb shell pm uninstall -k --user <n> <PACKAGE_NAME>

D.h. ich habe von den deinstallierten Apps aus meiner Debloatliste nun noch ein paar MB Appspeicher auf meinem Gerät.

Falsch!! Dieser Teil der Kommentars ist sehr schlecht recherchiert, auch wenn es noch so in idealo.de steht! Die Hersteller bzw. zumindest Samsung unterstützen ihre Geräte inzwischen über mehrere Jahre mit Updates und Upgrades wie bereits beschrieben:

Ein aktualisiertes Hersteller-Android ist natürlich immer noch ein Stock-ROM.

Ursprünglicher Debloat, wie bereits beschrieben. ADB-Befehlssequenz am erwähnten Samsung SM-T225, Galaxy Tab A7 Lite LTE mit Android 14, gerade getestet für App com.samsung.android.calendar, die zu dem Zeitpunkt deinstalliert war und aus der Kommandozeile direkt hierher kopiert:

gta7lite:/ $ pm install-existing com.samsung.android.calendar
Package com.samsung.android.calendar installed for user: 0
gta7lite:/ $ pm uninstall com.samsung.android.calendar
Failure [DELETE_FAILED_INTERNAL_ERROR]
1|gta7lite:/ $ pm uninstall -k com.samsung.android.calendar
Failure [DELETE_FAILED_INTERNAL_ERROR]
1|gta7lite:/ $ pm uninstall --user 0 com.samsung.android.calendar
Success
gta7lite:/ $ getprop ro.build.version.release
14
gta7lite:/ $ exit
C:\adb>adb shell pm install-existing com.samsung.android.calendar
Package com.samsung.android.calendar installed for user: 0
C:\adb>adb shell pm uninstall com.samsung.android.calendar
Failure [DELETE_FAILED_INTERNAL_ERROR]
C:\adb>adb shell pm uninstall --user 0 com.samsung.android.calendar
Success

Ergo:
Der ADB-Befehl uninstall produziert ohne den Zusatz --user <n> eine Fehlermeldung, der Befehl install-existing dagegen nicht. Android 14 ist installiert (Befehl getprop ro.build.version.release)!

1 „Gefällt mir“

Update dazu: Der ursprüngliche Debloater wird wohl nicht mehr weiterentwickelt. Es gibt nun aber einen Fork, der das Ganze fortsetzt: Google-Apps und weitere Bloatware loswerden mit dem "Universal Android Debloater Next Generation"

1 „Gefällt mir“

@caos : Danke für Deinen Hinweis. Ich mir daraufhin den neuesten Stand des Quellcodes des Universal Android Debloater - Next Generation (UADB-NG) von github.com besorgt, den Quellcode des UADB-NG kompiliert und daraufhin den UADB-NG auf mein Smartphone mit Android 10 angewendet.

Vorher hatte ich den UADB (alte Version und NG-Version) noch nie auf mein Smartphone angewendet.

Der UADBG-NG deaktivierte ca. 87 Bibliotheken bzw. Programme auf meinem Smartphone, gab aber nur ca. 1 GB bis dahin belegten Speicherplatz frei. Nach dem Reboot fehlte auf dem Startbildschirm die Anzeige von Datum, Uhrzeit und der Wetterbericht, das entsprechende Widget konnte ich aber ohne Probleme wieder auf meinen Startbildschirm platzieren, also wieder herstellen.

Die restlichen Apps in meinem Smartphone funktionieren wie gehabt, so weit ich das bisher beurteilen kann.

1 „Gefällt mir“

Wenn ich die Checksum verifiziere vom Download der Githubseite stimmt sie nicht überein…

Meinst Du die Datei von hier? https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/releases/tag/v1.0.3
Bei mir kommen da die richtigen Werte raus mit „sha256sum uad-ng-linux“ bzw. uad-ng-linuxtar.gz

Ja, ich habe allerdings nur Windows und mit Powershell und Get-Filehash uad-ng-windows.exe-checksum.txt getestet.