Datensparsames Android mit der Android Debug Bridge. Teil 3: Weitere Geräte und Plattformen

In diesem dritten und letzten Teil der Serie wird untersucht, inwieweit sich der Ansatz, ein vorinstalliertes Android Stock-ROM datensparsam umzubauen auf weitere Geräte und Plattformen übertragen lässt.
Die Methode ein Android Stock-ROM datensparsam umzubauen hatte ich erstmals an einem Asus ZenPad P024 unter Android 6 schon vor Jahren erprobt, mit ähnlich gutem Erfolg wie beim Samsung Phablet aus den ersten beiden Teilen (1), (2). Der Datenfluss zu Google und Asus ließ sich fast vollständig unterbinden. Dieses Asusgerät ist aber nun schon länger nicht mehr aktuell. Relevanter sind meine Erfahrungen mit den folgenden Geräten:

 1. Google Pixel 4a und 6a

Bei Google Pixelgeräten funktioniert der Ansatz mit dem Stock-ROM Datenschutz zu erreichen 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 ohnehin sinnlos, da für diese alle guten Custom-ROMs verfügbar und einfach zu installieren sind.

2. Xiaomi Redmi Note 10S

Datenschutz und Chinahandys schließen sich aus! In den zitierten Untersuchungen aus den ersten beiden Teilen von Leith et al, 2021 (1) und des IMDEA-Instituts (2), schnitten chinesische Hersteller und Apps im Allgemeinen deutlich schlechter ab, als ihre Pendants westlicher Hersteller. Leith hat nachgewiesen, dass Xiaomi das Öffnen und Schließen jedes Appfensters mit Zeitstempeln protokolliert und damit über die Dialer-App auch Beginn und Ende jedes Telefongesprächs. Das gemessene Datenvolumen für Telemetrie war nach Leith für die drei untersuchten chinesischen Hersteller Xiaomi, Huawei und Realme am größten. Eine alternative Standortberechtigung, wie von mir im zweiten Teil nur theoretisch beschrieben, die für den durchschnittlichen Nutzer nicht sichtbar und nicht abschaltbar ist und über die der Gerätestandort weitergegeben werden kann,  wurde vom IMDEA-Institut (2 – pre-installed Android Software) tatsächlich bei den chinesischen Herstellern Huawei und Oppo gefunden (android.permission.BAIDU_LOCATION_SERVICE). Sie ist sogar falsch deklariert und gibt vor, als Android-Berechtigung daherzukommen. Xiaomi wurde überführt, Fotos, SMS, Emails, und die Webadresse jeder über seinen Browser geöffneten Seite auf seine Server hochzuladen und beschuldigt, eine Zensurfunktion auch in seine Smartphones für westliche Märkte eingebaut zu haben (3). Weiterhin hatte Xiaomi eine Taschenrechnerapp ausgeliefert, die Standortdaten und die Telefondaten der SIM-Karte erfasste. Auch OnePlus hatte in der Vergangenheit exzessive Telemetriedaten mit eindeutigen Nutzer-IDs auf seine Server hochgeladen, sowie Smartphones mit einem Rootkit ausgeliefert, das über einen einfachen ADB-Befehl den dauerhaften Root der Geräte ermöglichte (2 – pre-installed Android Software). Das IMDEA-Institut hat chinesische App-Stores untersucht (u.a. Huawei, Xiaomi, Oppo, Lenovo) und dabei eine hohe Rate an veralteten Apps, sowie „eine höhere Prävalenz von gefälschten, geklonten und bösartigen Apps in chinesischen Stores als in Google Play“ gefunden (4). Diese Liste ließe sich fortsetzen. Unabhängig von der Qualität und Quantität der Datenübertragung bleibt das grundlegende Dilemma chinesischer Smartphones, dass die gesammelten Daten unter die Kontrolle des größten Überwachungsstaates der Welt geraten. Während in den USA eine andere Vorstellung von Datenschutz herrscht als in Europa, existieren die Konzepte von Datenschutz und Bürgerrechten in der Volksrepublik China überhaupt nicht.

Leider findet man gerade in Kinderhänden viele Smartphones aus China, wahrscheinlich weil sie am billigsten sind, so auch in meinem Bekanntenkreis. Verdienen Kinder und Jugendliche etwa keine Privatsphäre? Ich habe versucht bei einem Redmi Note 10S mit Android 12 aus dem Hause Xiaomi den Datenabfluss soweit wie möglich zu reduzieren. Das gelang deutlich schlechter als beim aktuellen Samsung Stock-ROM. Xiaomi hat seine Dienste tiefer in Android integriert als Samsung. Damit lassen sich „nach Hause funkende“ Systemapps nicht im selben Umfang entfernen, ohne grundlegende Funktionen des OS zu beschädigen. Es bleibt ein signifikanter Datenfluss an Xiaomi-Server unter chinesischer Kontrolle bestehen, der nur mit einer Firewall weiter reduziert werden kann. Immerhin lässt sich das Datenvolumen an Xiaomi signifikant reduzieren und viel lästige Bloatware entfernen. System- und Sicherheitsupdates funktionieren weiterhin. Ein Teil der zitierten Probleme mit chinesischen Herstellern lässt sich durch Deinstallation der verursachenden Systemapps abstellen, sofern diese identifiziert werden können. Debloatlisten für Xiaomi mit mehreren Ergänzungen, davon auch eines von mir, gibt es u.a. auf Github (5). Apps, die nicht entfernt werden sollten, sind mit aufgeführt. Bei dieser Liste bestand nicht das Ziel, die Googledienste vollständig zu entfernen.

3. Android TV auf Nvidia Shield

Ich verbinde kein Fernsehgerät direkt mit dem Internet, da in diesem Fall auch linearer Fernsehkonsum 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 11 läuft. Ein weiterer Vorteil der Shield ist, dass Streaming auch von einem Heimserver, wie einem NAS möglich ist. Die meisten vernetzten TVs dürften damit überfordert sein.
Android TV ist mit mindestens so viel Werbung und nach Hause funkender Bloatware gefüllt, wie mobile Androiden. Der Ansatz diese Bloatware zu entfernen, wenn nötig mit der ADB ist daher auch für diese Plattform zu empfehlen. Die Einstellungen-App ist unter Android TV stark abgespeckt. Die Funktionen, die in den Einstellungen nicht sichtbar sind, können dennoch über die ADB zugänglich sein. Das Vorgehen unter Android TV ist analog zu dem für mobile Geräte beschriebenen, bis auf die folgenden Besonderheiten von Android TV:

• Um kein USB-Kabel zwischen Fernseher und PC spannen zu müssen, kann WiFi-Debugging als ADB-Schnittstelle genutzt werden. Anleitungen dazu und zur Aktivierung der Entwickleroptionen gibt es im Internet. Über die ADB funktioniert das Sideloading von Apps in Form von APK-Dateien.
• Der F-Droid App Store lässt sich auf der Nvidia Shield unter Android TV installieren. Dort gibt es einige FOSS-Apps, die unter Android TV sehr gut funktionieren, obwohl es sich nicht um spezielle TV-Varianten für eine Bedienung ohne Touchscreen handelt: Der VLC Player, Kodi Medienplayer, Amaze Filemanager, NewPipe, eine Galerie App, Zapp zum Zugriff auf Mediatheken der öffentlich-rechtlichen Sender. Android TV wird oft ohne vorinstallierten Browser ausgeliefert. Der Fennec-Browser eignet sich ausgezeichnet für Android TV, da er das Widevine CDM Plugin zur Wiedergabe von per DRM verschlüsselten Medieninhalten mitbringt, welches Android-Browsern häufig fehlt. Die Wiedergabe von DRM-Inhalten ist eine Voraussetzung zur Nutzung vieler Streamingdienste im Browser. Der Package Manager kann zur Administration von Apps verwendet werden. Um Werbung auf dem Homescreen zu unterbinden, empfiehlt sich ein alternativer TV Launcher wie der FLauncher (Playstore).
• Android TV bringt keine Einstellungen für Standard Apps mit, um z.B. den voreingestellten Launcher durch eine Alternative wie FLauncher zu ersetzen. Damit das Gerät dennoch gleich beim Boot einen alternativen Launcher startet, bietet sich diese Methode an: Den alternativen Launcher installieren, manuell starten und testen. Danach den Standard Launcher deaktivieren. Auch für die Deaktivierung von Apps kann unter Einstellungen / Apps der Schalter fehlen. Die Deaktivierung funktioniert mit diesem ADB-Befehl dennoch, hier am Beispiel des Google-Launchers: adb shell pm disable-user com.google.android.tvlauncher Diese Methode ist auf eigene Gefahr anzuwenden, denn wenn kein Launcher startet und das Gerät weder über die Einstellungen noch die ADB angesprochen werden kann, bleibt nur noch ein Zurücksetzen auf Werkseinstellungen über das Recovery-Menu.
• Android TV stellt an sich mehrere Nutzerprofile zur Verfügung, aber kein Arbeitsprofil, das für Firmenanwendungen entwickelt wurde (MDM), die von Google nicht für Fernsehgeräte vorgesehen sind. Bei der Nvidia Shield ließen sich weitere Profile jedoch nicht aus den Einstellungen, sondern nur per ADB aktivieren, löschen mit "adb shell pm create-user (remove-user) <user id>". Damit ist die Methode, kritische Apps in weitere Nutzerprofile zu verlagern wenig praktikabel.
• Die Google App heißt unter Android TV "com.google.android.katniss". Solange sie und die Play Dienste App aktiv sind, wird die Gerätenutzung wie in der mobilen Google-App durch Google durchgehend 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. Ein Problem ist, 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. Ich möchte aber davor warnen, den Aurora Store in einem Nutzerprofil zu verwenden, das mit Googlekennung angemeldet ist. Auf diversen Foren wird davor gewarnt, dass Google solche Konten stilllegt. Weitere alternative Quellen für spezifische Android TV Apps sind Plattformen wie APK-Mirror.
• RethinkDNS läuft auf der Shield im Prinzip, die automatische Aktivierung nach einem Neustart funktioniert aber nicht. Daher benutze ich zum Filtern noch ein altes Blokada V4.15 welches automatisch startet. Es wird allerdings nicht mehr weiterentwickelt und wurde aus F-Droid entfernt. Als weitere alternative Filterapp kann daher der personalDNSfilter aus F-Droid verwendet werden.
• Die App für Systemupdates heißt bei der Nvidia Shield "com.nvidia.ota.apk", 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 Samsung-Phablet. Die Nvidia Shield eignet sich nicht nur zum Streamen von Medien, sondern auch zum Gaming über verschiedene Kanäle. Welche Systemapps deaktiviert werden können, hängt daher stark vom Nutzungsverhalten ab. Wer Gaming nutzen will, muss mehr Datenverkehr zu Nvidia zulassen. Bloatlisten sind daher sehr subjektiv und ich kann keine allgemeingültige zur Verfügung stellen. Der Homescreen der umgebauten Shield ist im Titelbild zu sehen. Neben FOSS-Apps laufen selbstverständlich auch kommerzielle Apps, wie die der großen Streaminganbieter.

4. Tolino Shine 3 Ebook Reader

Der Tolino besteht aus einem Unterbau aus Android auf dem im Kioskmodus die Tolino Ebook-App "de.telekom.epub" läuft, d.h. alle für den Nutzer zugänglichen Funktionen, inkl. Systemupdates und Browser sind in diese App integriert. Mit Hilfe von Fastboot und der ADB ist es möglich, die Androidoberfläche zu erreichen, Launcher und andere Apps aufzuspielen oder das Gerät zu Rooten (6). Die ADB-Schnittstelle alleine kann deutlich einfacher mit einem „geheimen“ Code aktiviert werden, der für verschiedene Tolinomodelle funktioniert (7).

Zuerst schauen wir uns aber den Datenverkehr des Tolino an, den ich anlässlich dieses Artikels noch einmal für die aktuelle Firmwareversion 16.2 an der Fritzbox aufgezeichnet habe. Der Tolino kontaktiert neben öffentlichen Zeitservern im Wesentlichen die folgenden Domains und davon abgeleitete Subdomains:

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

Diese Adressen werden auch kontaktiert, wenn das Gerät nur zum Lesen verwendet wird, also keine Inhalte heruntergeladen werden müssen. Es findet also Tracking des Nutzer- bzw. Leseverhaltens statt.  "pageplace.de" ist die Domain des App- und Geräteentwicklers Kobo Rakuten, über die Updates eingespielt werden. Sie läuft nicht auf einem deutschen, sondern einem US-Server. "mytolino.com" und "thalia.de" stellen den Ebook Shop und die Inhalte bereit. "clients3.google.com" wird jedes Mal kontaktiert, wenn das Gerät aus dem Standby gestartet wird. Bei längerem Lesen wird die Verbindung auch während der Nutzung aufgerufen. Das ist verwunderlich, da das Android des Tolino keine einzige vorinstallierte App von Google enthält. Wahrscheinlich enthält die Tolino-App Code (SDKs) oder Dienste von Google. Das Pendant der Tolino-App für Smartphones, Tablets aus dem Playstore enthält die Google-Tracker Crashlytics und Firebase (siehe Exodus Privacy). Vergleichbarer Code könnte auch in der Ebook-App verbaut sein.
Beim Start des Browsers konnte ich für die Firmwareversion 16.2 keine weiteren Verbindungen zu Trackern identifizieren.

Ich hatte zuerst den unter (6) beschriebenen Hack durchgeführt, um eine vollständige Androidoberfläche zu erhalten und Apps aufspielen zu können. Der Tolino ließ sich damit über die ADB ansteuern und analysieren. Der Unterbau besteht noch aus Android 4.4. „Kitkat“, das 2013 auf den Markt kam! Es besteht nur aus ca. 30 Systemapps – Android 14 hat ca. das zehnfache. Wie gesagt fehlen die Google-Dienste und Systemapps vollständig. Die wichtigste Systemapp ist die bereits genannte Ebook-App "de.telekom.epub". Der Browser, der darin enthalten ist, hat diesen User Agent (verkürzt):

Mozilla/5.0 (Linux; Android 4.4.2; de-; tolino shine 3/16.2.0) … Chrome/30.0.0.0 Mobile Mobile … OS_BUILD/KOT49H.157800.d4fd989

Es handelt sich also um einen Chrome V.30, der so veraltet ist wie Android 4.4. Darüber hinaus legt der Browser die Antiquiertheit des Systems in allen Details offen, inkl. der Buildnummer! Potentielle Angreifer können sich freuen!

Abb.: Menüs, die nur die wenigsten Tolinonutzer sehen:

Das Debugmenü kann über einen Code freigeschaltet werden (7). Danach kann das Debugmenü permanent zugänglich gemacht werden (show debug dialog), die ADB und USB-Debugging lassen sich aktivieren und von Android lässt sich das Einstellungsmenü erreichen (open AOSP). Dort zeigt sich, dass auch im Jahr 2024 noch ein „Update“ bestehend aus Android 4.4.2 ausgeliefert werden kann! Der Entwickler KO-BO verrät sich im Code der Buildnummer.

Über die ADB konnte ich den F-Droid Store installieren (eine alte Android 4.4 kompatible Version verwenden) und aus F-Droid Apps installieren, die noch für Android 4.4 geschrieben sind, wie den PrivacyBrowser, den TotalCommander, sowie die VPN-Firewall Apps PersonalDNSFilter und tPacketCapture (Playstore). Die Apps funktionierten, allerdings waren die Firewall Apps nicht in der Lage, den Datenverkehr zu filtern. Der Grund dürfte sein, dass das rudimentäre Android 4.4 des Tolino kein VPN 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 Ebook-App konzentriert sind.

Als nächstes habe ich mir die Tolino Ebook-App mit der ADB genauer angeschaut. Der Befehl
adb shell dumpsys package de.telekom.epub
zeigt Appeigenschaften und Berechtigungen an. Die App hat 71 „granted“ Android Standardberechtigungen, darunter sehr exklusive Signature-Berechtigungen, die für Systemapps reserviert sind, da erzeugende und empfangende App dasselbe Zertifikat haben müssen. Hier ist eine kleine Auswahl der bemerkenswertesten Berechtigungen:

android.permission.ACCESS_COARSE_LOCATION
android.permission.ACCESS_FINE_LOCATION
android.permission.READ_LOGS               
android.permission.INSTALL_PACKAGES           
android.permission.MOUNT_UNMOUNT_FILESYSTEMS       
android.permission.COPY_PROTECTED_DATA           

Die letzten 4 dieser Berechtigungen deuten an, dass die Tolino-App die zentrale App des Systems ist, die für Updates und Speicherverwaltung zuständig ist. Die Standortberechtigungen sind für einen E-Reader verwunderlich. Die App hat auch Berechtigungen wie READ_PHONE_STATE, die mangels vorhandener Hardware nutzlos sind. Unter den abgezählten Systemapps ist aber „com.android.location.fused“, die laut Google das API „für kombinierte Standortbestimmung … wie GPS und WLAN“ ist. Daher könnte der Tolino eine Standortbestimmung über die in Reichweite befindlichen WLAN-Netze vornehmen und diese Daten weitergeben. In der Android Logdatei, die im zweiten Teil behandelt wurde (2) finden sich die MAC-Adressen und SSIDs der verbundenen WLAN-Netze, die den Nutzer und seinen Standort eindeutig identifizieren. Die Tolino-App hat die READ_LOGS Berechtigung um diese zu lesen.
Daher stellt sich hier die Frage, ob die Standortdienste aktiv und welche Sensoren vorhanden sind. Beim Tolino lässt sich das nicht durch Installation von Admin-Apps herausfinden, wie in Teil 2 beim Samsunggerät (2). Die ADB hilft hier wieder weiter. Mit dem Befehl adb shell dumpsys sensorservice lässt sich der Status der Sensoren auslesen, mit dem Befehl adb shell dumpsys location der Status der Standortdienste.  
Der Tolino hat tatsächlich Beschleunigungssensoren, Gyroskope und einen Lichtsensor. Die ADB-Abfrage zeigt sie bis auf den Lichtsensor als inaktiv an. Für die Standortdienste gibt die ADB-Abfrage dieses Ergebnis:

…
REMOTE SERVICE name=fused pkg=com.android.location.fused version=0
mEnabled=false null
fused=null
gps Location[ 0,000000,0,000000 acc=340282346638529 t=?!? et=?!?]
    UNAVAILABLE ---
net Location[ 0,000000,0,000000 acc=340282346638529 t=?!? et=?!?]
    UNAVAILABLE ---

Es wird der Status der Standortermittlung über GPS und WLAN-Netze angezeigt. Keiner dieser Standortdienste scheint aktiv zu sein. Es zeigt sich aber, dass die Standortdienste vorhanden sind und etwa durch ein Update scharf geschaltet werden könnten. Die Tolino-App könnte Standorte auch immer noch durch Auslesen der WLAN SSIDs und MAC-Adressen aus der Logdatei weitergeben. Vorsichtige Nutzer können den Tolino daher in den Flugmodus versetzen, wenn sie unterwegs sind. Den Systemapps die Standortberechtigung mit der ADB zu nehmen funktioniert nicht, ähnlich wie beim vergleichbaren Versuch am Samsung Phablet (2). Ebensowenig kann die Systemapp „com.android.location.fused“ mit der ADB ohne Root deaktiviert oder deinstalliert werden.

Zuletzt habe ich eine alternative Ebook-App installiert. In F-Droid gibt es den KOReader. Er funktioniert und damit würde der Tolino zum Open-Source Reader, wenn die Tolino-App entfernt würde, was hier aber nicht das Ziel war. Im Internet lassen sich weitere Anleitungen zu derartigen Umbauten am Tolino finden. Eink-Displays benötigen allerdings spezielle Graphiktreiber, die auch Teil der Tolino-App sind. Mit alternativen Ebook-Apps sehen die Seiten schlechter aus (Stichwort: Ghosting) und Ebooks mit DRM können nicht mehr sicher geöffnet werden. Updates werden ohne die Tolino-App auch nicht mehr eingespielt.

Die Möglichkeiten am Tolino sind also beschränkt. Dennoch ist mit der ADB eine sehr detaillierte Analyse dieses geschlossenen Systems möglich, von dem der Nutzer nur die Tolino-App im Kioskmodus sehen soll. Wer den Tolino datenschutzfreundlich betreiben will, kann das einfach erreichen, indem das Gerät nicht mit dem Internet verbunden wird und Ebooks per USB-Kabel aufgespielt werden. Mit dem völlig veralteten, unsicheren Android 4.4 Unterbau sollten ohnehin keine Verbindungen zu nicht vertrauenswürdigen WLAN-Netzen und Webseiten aufgebaut werden.
 

Gesamtfazit

Soweit mein Exkurs durch verschiedene Android-Plattformen und die ADB. Es wurde deutlich, dass je nach Plattform und Hersteller die Chancen sehr unterschiedlich stehen, Tracking durch die vorinstallierten Systemapps des Herstellers und von Google ohne Root zu reduzieren. Durch die Deinstallation, Deaktivierung von „nach Hause funkenden“ Systemapps, sowie die Blockade verbleibender Verbindungen mit einer Firewall kann im günstigsten Fall eine Reduktion des hochgeladenen Datenvolumens und der Datenfrequenz um ca. einen Faktor 100 gegenüber dem Auslieferungszustand erreicht werden.  Damit wird in Bezug auf die Privatsphäre annähernd der Standard besserer Custom-ROMs erreicht. In diese Kategorie fällt das aktuelle Samsung Stock-ROM unter Android 14, sowie die Nvidia Shield mit Android TV. Andererseits funktioniert der Ansatz beim Tolino Shine 3 Ebook Reader und Google Pixel Smartphones überhaupt nicht. Beides sind Sonderfälle. Der Tolino ist ein geschlossenes System mit nur einer Anwenderapp, die Pixel sind die einzigen Androidgeräte, bei denen Hardware- und Betriebssystemhersteller identisch ist. Bei einem Xiaomi Redmi Smartphone funktionierte der Ansatz nur mit mittelmäßigem Erfolg.

Von den Sonderfällen abgesehen, hängt der Erfolg des Ansatzes entscheidend davon ab, wie Nahe ein Hersteller mit seiner Variante am Standard des Android Open Source Projects (AOSP) bleibt. Je mehr der relativ sauberen AOSP-Systemapps durch Pfuscherei der Hersteller ersetzt wurde, umso weniger erfolgsträchtig ist ein Rückbau in Richtung AOSP. Wer plant nach dem Kauf eines neuen Gerätes den beschriebenen Ansatz zu verfolgen kann unter Einstellungen / Apps einen Blick auf die Systemapps werfen und prüfen, ob es sich dabei hauptsächlich um AOSP- („com.android….“) oder Herstellerapps handelt („com.hersteller….“).

Bei Anschaffung eines neuen Gerätes ist der einfachere und erfolgreichere Ansatz zu einem datensparsamen Android allerdings die Wahl eines Gerätes, auf dem gute Custom ROMs wie GrapheneOS, DivestOS, CalyxOS oder IodéOS laufen, wie bereits im ersten Teil erläutert wurde (1). Wenn dafür Sicherheitsanforderungen wie ein geschlossener Bootloader gestellt werden, kommen dafür aber nicht viel mehr Geräte als die Pixelreihe von Google und das Fairphone in Frage.

Wie sinnvoll ein Rückbau der Stock-ROMs in Richtung AOSP ist, zeigt ein Beispiel: Das Google Pixel 6a wird mit dem Google Stock-ROM unter Android 14 mit ca. 270 Systemapps ausgeliefert und ist damit immer noch vergleichsweise arm an Bloatware. GrapheneOS kommt beim selben Pixel 6a mit ca. 165 Systemapps aus. Alles darüber hinaus ist also Ballast, der einem auf Privatsphäre bedachten Nutzer nur Nachteile bringt, in Form von ununterbrochenem Tracking, Verbrauch mobiler Daten, kürzerer Batterielaufzeit und überfülltem Speicher. Es gibt also keine guten Gründe überflüssige Bloatware nicht zu entfernen.

Im Internet sind zwar hunderte Bloatlisten für alle gängigen Androidgeräte veröffentlicht. Was fehlt, sind Informationen dazu, was das Debloating bewirkt, wie weit das Tracking damit für ein bestimmtes Geräte reduziert wird und ob Funktionen eingebüßt werden. Ich konnte diese Daten hier nur für wenige Geräte veröffentlichen und würde daher Leser dazu ermutigen, weitere Geräte zu erfassen und die Daten dazu zu veröffentlichen.

Also viel Erfolg beim Debloaten und der Übernahme der Kontrolle über Eure Androiden!

Literatur:

(1) https://gnulinux.ch/datensparsames-android-mit-der-android-debug-bridge-teil1-samsung-phablet
(2) https://gnulinux.ch/datensparsames-android-mit-der-android-debug-bridge-teil-2-berechtigungen-und-sensoren 
(3) https://de.wikipedia.org/wiki/Xiaomi
(4) IMDEA, Chinese App Markets, 2018, https://dspace.networks.imdea.org/bitstream/handle/20.500.12761/618/imc18-final148.pdf
(5) https://gist.github.com/mcxiaoke/ade05718f590bcd574b807c4706a00b1
(6) https://allesebook.de/anleitung/tolino-shine-3-adb-root-und-eigene-apps-installieren-video-978782/
(7) https://gist.github.com/hasezoey/d16ba0f980f00cd2193132afe4714c7c

Dieser Artikel ist Teil einer Artikelserie

Teil 1: Samsung Phablet
Teil 2: Berechtigungen und Sensoren
Teil 3: Weitere Geräte und Plattformen