Ich bin mit einem Xperia Z in die Android-Welt eingestiegen. Das war damals schon nicht mehr auf dem neuesten Stand – und generell waren die Supportzeiträume für Android-Geräte extrem kurz. Da wurde ein Gerät mit einem Betriebssystem auf den Markt geworfen, und gefühlt war es das dann mit Software-Support.
Ich mochte Android anfangs nicht. Mittlerweile ist es meiner Meinung nach eines der besten mobilen Betriebssysteme - gewesen – weil es den Nutzer:innen unglaublich viele Möglichkeiten bot, das System bis ins kleinste Detail zu modifizieren und anzupassen.
Dank Root-Zugriff (damals noch über SuperSU) war das sogar möglich, ohne sich groß mit Kompilierung oder ähnlichem auszukennen.
Ich bin relativ früh auf CyanogenMod umgestiegen – den geistigen Vorgänger von LineageOS.
Root habe ich primär zur vollständigen Datensicherung genutzt, aber auch für zahlreiche optische und technische Anpassungen – teils sogar, um softwareseitige Versäumnisse der Hersteller eigenständig zu beheben.
Root war für mich also im Alltagsgebrauch essenziell.
Meine Geräte waren öfter aber nie dauerhaft gebrickt – am längsten lag mal ein Nokia 5 zur Seite, bis ich herausgefunden habe, wie der EDL-Modus funktioniert. Aber durch meine vielen Experimente habe ich da viel Wissen erwerben und vertiefen können. Ich experimentiere eben gerne. Irgendwann entdeckte ich zusätzlich zum Root-Zugriff auch Xposed, was meine Android-Nutzung auf ein ganz neues Level gehoben hat.
AFWall+ (funktioniert seit Android 10 nur noch eingeschränkt), XPrivacy (später XPrivacyLua) sowie diverse Tools zur Kontrolle von Services, Broadcasts und Aktivitäten in Apps gehörten für mich immer zum Standard-Repertoire.
Teilweise hatte ich gefühlt tagelange Akkulaufzeiten meiner Geräte, weil die Netzwerkverbindung nur alle 15 Minuten für eine Minute aktiviert wurde. Heute geht das nicht mehr, da Aktionen bei deaktiviertem Display nur noch sehr beschränkt ausgeführt werden können.
Mit Android 8 und der Einführung von System-as-Root sowie später System-as-Read-Only wurden solche tiefgreifenden Modifikationen jedoch zunehmend schwieriger. Das war auch die Zeit, in der sich Magisk als neue Root-Lösung etablierte – systemlos, modular und mit Unterstützung für Module.
Zeitgleich wuchs bei Google das Bewusstsein für Grundlegende Systemsicherheit – insbesondere im Kontext von Vermeidung von Root und Systemmodifikationen.
Dank Magisk-Overlays konnte vieles aufgefangen werden, und die Möglichkeit, Änderungen rückgängig zu machen, war ein enormer Vorteil gegenüber früheren Methoden.
Xposed wurde irgendwann nicht mehr weiterentwickelt. LSPosed hat diese Lücke geschlossen. Durch dessen modulare Architektur (z. B. über Scope-Einstellungen) waren sogar fein granulierte Modifikationen möglich.
Android hat sich seither weiterentwickelt. In puncto Sicherheit definitiv zum Besseren – zumindest für Durchschnittsnutzer:innen. Für Modder wurde es jedoch zunehmend schwieriger.
Die Erkennungsraten für Root und Systemmodifikationen stiegen. Das System arbeitet inzwischen aktiv dagegen. Der Hauptentwickler von Magisk arbeitet heute übrigens bei Google – was einiges erklärt.
Ich denke, das war ein Wendepunkt. Google – und damit auch das AOSP-Projekt – begann ein regelrechtes Katz-und-Maus-Spiel mit der Modding-Community. Dieses mündete in SafetyNet, dem Vorläufer der heutigen Play Integrity API.
Damals hat man darüber noch gelacht – betroffen waren z. B. nur Spiele wie Pokémon GO (was sowieso keiner benutzt hat), deren Integritätsprüfung sich mit Magisk Hide oder LSPosed leicht umgehen ließ. Heute betrifft das aber immer mehr Apps.
Gerade bei sicherheitsrelevanten Anwendungen wie Banking-Apps ist es nachvollziehbar, dass sie Root-Erkennung betreiben. Wenn aber (übertrieben gesagt) eine Taschenlampen-App den Dienst verweigert, weil die Integritätsprüfung fehlschlägt, ist das meiner Meinung nach übertrieben.
Mit der Play Integrity API ist es einfacher denn je, Integritätsprüfungen in Apps zu integrieren – und gleichzeitig deutlich schwerer, diese zu umgehen.
Ich habe mit meinem begrenzten Android-Fachwissen viel Zeit darauf verwendet, mein Gerät vom System her „normal“ erscheinen zu lassen und trotzdem die Vorteile von Modding zu nutzen. Teilweise war alle zwei bis drei Wochen irgendeine neue Anpassung notwendig (verstecken von Apps, Signaturanpassungen weil Google reagiert, etc...).
Das macht mir zwar Spaß, erfordert aber auch viel Zeit für Recherche, Tests – und gelegentlich eine frustrierte Pause wenn es nicht läuft.
Jetzt, 2025, haben wir den Punkt erreicht, an dem allein das Entsperren des Bootloaders bereits dazu führt, dass bestimmte Funktionen des Smartphones nicht mehr nutzbar sind.
Das Shiftphone 8 mit NFC und Fingerabdrucksensor ist da kein Einzelfall.
Ich nutze NFC auch für andere Zwecke als mobiles Bezahlen – darauf möchte ich nicht verzichten. Meine Passwörter sind lang – ich möchte sie nicht jedes Mal manuell eingeben weil der Fingerabdruck nicht funktioniert.
Viele Apps bieten inzwischen interne Backup-Funktionen. Die Firewall, der ich vertraute, funktioniert nicht mehr. Die Hälfte meiner Apps stürzt ab, wenn ich sie in die Scope-Liste von XPrivacyLua aufnehme, was diese Option auch obsolet werden lässt. Manche Apps funktionieren gar nicht mehr oder löschen sogar ihre Daten, wenn die gefälschte Zertifizierung (bspw. mit Zygisk-Module) kurzfristig nicht mehr greift.
Der Aufwand für Root steht meines Erachtens heute in keinem sinnvollen Verhältnis mehr zum Nutzen – obwohl ich nach wie vor ein großer Verfechter davon bin und gerne experimentiere.
Die Kosten-Nutzen-Analyse fällt aber aktuell zugunsten des Stock-Systems aus – gemessen am Aufwand den ich betreiben muss.
Ich vermisse viele der früher möglichen Runtime-Modifikationen. Gleichzeitig genieße ich aber auch den „Frieden“, den ein "stabil" laufendes System mit sich bringt.
Ich bin gespannt, was die Zukunft bringt. Wenn ich jedoch in einschlägige Threads bei XDA reinschaue, habe ich immer stärker das Gefühl:
„Root-Zugriff und gleichzeitig alle Funktionen eines Smartphones uneingeschränkt nutzen“ – das war einmal.
Ich hoffe, das war Erklärung genug
.
Greetz
.
.
.
