Beste Magisk-Module 2026: verifizierte Quellen und was eingestellt wurde

Mehrere Module, die auf aktuellen Listen noch auftauchen, existieren gar nicht mehr. Play Integrity Fix wurde von seinem Autor von GitHub gelöscht. Universal SafetyNet Fix hatte sein letztes Release im Januar 2023. Und der Schritt „über das Online-Repository der Magisk-App installieren", den die meisten Anleitungen beschreiben, bezieht sich auf eine Funktion, die vor Jahren aus Magisk entfernt wurde. Jedes Projekt unten wurde vor der Aufnahme gegen sein eigenes Repository geprüft, und jedes hat einen Link.

Zuletzt technisch verifiziert: 30. Oktober 2026
Magisk-Basis: v31.1 (veröffentlicht am 25. Oktober 2026)
Deckt außerdem ab: KernelSU, KernelSU Next, SukiSU Ultra und APatch
Android-Abdeckung: 12 bis 17, neuere Versionen nur dort erwähnt, wo ein Projekt sie ausdrücklich unterstützt
Aktualisiert am 30. Oktober 2026: Magisk 31.0 und 31.1 (neue App, keine Root-Pop-ups mehr, App-Verstecken entfernt), aktuelle Versionen jedes Root-Managers und jeder Zygisk-Implementierung, quelloffene Tricky-Store-Alternativen und mehrere mittlerweile archivierte oder veraltete Module
Quellenregel: nur offizielle Maintainer-Links. Wir spiegeln keine Modul-ZIPs

Die Kurzversion

Die meisten wollen eines von vier Dingen. Du brauchst nicht die ganze Liste.

Alles Weitere ist Detail zu diesen vier Punkten, plus was zu vermeiden ist.

Was sich geändert hat, und was raus muss

Wenn du einer älteren Anleitung folgst, bist du vielleicht dabei, etwas zu installieren, das es nicht mehr gibt.

Die letzte Zeile sorgt für die meiste Verwirrung. Nutzer öffnen Magisk, suchen den Modul-Download-Tab aus einer alten Anleitung, finden ihn nicht und gehen davon aus, ihre Installation sei kaputt. Ist sie nicht. Auffinden und Installieren sind jetzt getrennte Schritte: Modul auf GitHub finden, ZIP herunterladen, aus dem Speicher installieren.

Mehrere beliebte „Module" sind gar keine Module

Das ist wichtig, weil es ändert, wo du die Sache herbekommst und wie du sie reparierst, wenn sie sich daneben benimmt.

All das ist sinnvoll zu nutzen. Nichts davon flasht man. Eine Anleitung, die AdAway zwischen zwei Zygisk-Modulen listet, lehrt einen Kategorienfehler, und Leser, die dann nach einer „AdAway-ZIP" suchen, landen genau auf der Art Mirror-Seite, vor der dieser Artikel eigentlich warnt.

Was sich in Magisk 31.0 und 31.1 geändert hat

Magisk 31.1 ist die aktuelle Stable-Version (25. Oktober 2026) und ändert, wie sich Magisk im Alltag verhält. Die meisten älteren Anleitungen, auch frühere Versionen dieser hier, beschreiben noch den alten Ablauf. Laut offiziellen Release-Notes:

Root-Anfragen poppen nicht mehr auf. Superuser-Zugriff wird Apps jetzt im Voraus gewährt, über den Superuser-Tab in der Magisk-App. Wenn eine Terminal-App, ein Backup-Tool oder ein Modul sagt, es brauche Root, und nichts erscheint auf dem Bildschirm, öffne Superuser und erteile die Berechtigung dort zuerst. Dasselbe gilt für adb shell, das keine Vordergrund-App hat, in der eine Abfrage angezeigt werden könnte. Das Magisk-Team sagt, die alte reaktive Abfrage könne auf HSUM-Geräten nicht funktionieren.

Das Verstecken der Magisk-App ist weg. Die Repackaging-Funktion (den Manager in ein zufälliges Paket umbenennen) wurde entfernt, und Magisk installiert seine App nicht mehr neu, wenn sie fehlt. Der Rat der Entwickler ist deutlich: ein installiertes Paket wirklich zu verstecken, ist auf Android fast unmöglich, deshalb ist der wirksamste Weg, die Magisk-App zu verstecken, nachdem du deine Superuser-Richtlinien und Module eingerichtet hast, sie zu deinstallieren. Apps, die nach dem Manager suchen, sind ein weiterer Grund, sich auf die DenyList und die Verstecken-Schritte unten zu verlassen statt auf den App-Namen.

Bevor du ein funktionierendes Handy aktualisierst, notiere deine aktuelle Version, mache einen Screenshot der Superuser-Liste und hebe das Stock-Boot-Image für dein Build auf. Android-6.0-Handys bleiben auf 30.7.

Welchen Root-Manager nutzt du?

Magisk ist nicht mehr die einzige Option, und welchen du nutzt, entscheidet, was du installieren kannst. Module sind weitgehend portabel, aber nicht vollständig.

Zwei Dinge macht man hier oft falsch.

Du kannst nicht zwei gleichzeitig betreiben. Entferne eines vollständig, stelle das passende Stock-Image wieder her, dann installiere das andere. Beide gleichzeitig aktiv führt zu Konflikten.

KernelSU-Forks sind nicht austauschbar. KernelSU, KernelSU Next und SukiSU Ultra teilen Ideen, aber ihre Manager und Kernel-Änderungen unterscheiden sich. Nutze das Build, das für den Fork gemacht wurde, den du tatsächlich installiert hast.

Eine Anmerkung zu Magisk Alpha: Das ist ein inoffizielles Build, hauptsächlich über Telegram verteilt. Es hat eine Anhängerschaft, aber Quellcode und Release-Historie sind schwächer belegt als beim offiziellen Magisk, was bei etwas, das als Root läuft, zählt. Offizielles Stable lässt sich leichter überprüfen. ReZygisk zum Beispiel hat die Unterstützung für Magisk Alpha in v1.0.0 entfernt.

Was womit funktioniert

Die Zeile, die am meisten entscheidet, ist SUSFS. Es versteckt sich im Kernel statt im Userspace, was Userspace-Module strukturell nicht nachbilden können, und es funktioniert nicht mit Magisk, weil Magisk den Kernel nie anfasst. Das ist das zentrale technische Argument dafür, 2026 von Magisk wegzugehen, und es braucht ein Gerät mit kompatiblem Kernel, das nicht jedes Gerät hat. Unser Vergleich Magisk vs. KernelSU vs. APatch behandelt den Trade-off ausführlich.

Alles in diesem Artikel funktioniert mit Magisk. Wo etwas auf eine Familie beschränkt ist, steht das dabei.

Bevor du irgendetwas installierst

Mach einen Screenshot deiner aktuellen Module. Öffne deinen Root-Manager, gehe zum Modul-Tab, Screenshot der Liste. Das ist dein Protokoll, was sich geändert hat, falls etwas kaputtgeht. Fünf Sekunden, kein Terminal nötig.

Notiere dabei deine Magisk-Version und deinen Android-Build. Magisk zeigt seine Version auf dem Startbildschirm. Android-Version und Sicherheitspatch findest du in den Einstellungen unter Über das Telefon.

Ein Modul nach dem anderen, dann neu starten, dann prüfen, ob es funktioniert. Installierst du fünf und startest einmal neu, weißt du nicht, welches davon es kaputtgemacht hat.

Wisse, wie du wiederherstellst, bevor du es brauchst. Das steht am Ende dieses Artikels. Lies es zuerst.

Schritt 1: eine Zygisk-Implementierung wählen

Zygisk ist die Injection-Schicht, auf der Verstecken-Module und das Xposed-Framework aufbauen. Magisk hat eine eingebaut. KernelSU und APatch nicht, also brauchen diese Nutzer eine eigenständige. Magisk-Nutzer können statt der eingebauten auch eine eigenständige Implementierung wählen.

Drei Regeln, die zusammen die meisten Fehler verhindern, über die Leute berichten:

Genau eine laufen lassen. Installierst du eine eigenständige Implementierung auf Magisk, schalte zuerst das eingebaute Zygisk aus. Beide gleichzeitig laufen zu lassen ist ein häufiger, vermeidbarer Fehler.

Shamiko funktioniert nicht mit ReZygisk. Shamiko zielt auf eingebautes Zygisk und Zygisk Next. Wählst du ReZygisk, brauchst du ein anderes Verstecken-Modul. Das zu mischen ist die klassische Ursache für „mein Verstecken hat gestern funktioniert und heute nicht mehr". Dasselbe gilt für Zygisk Assistant.

Deinstalliere das alte, bevor du wechselst. Migrieren ohne vorheriges Entfernen des alten Moduls hat schon Bootloops verursacht, besonders bei Änderungen der Modul-ID.

Die Lizenzänderung von Zygisk Next verdient eine bewusste Entscheidung statt eine Standardwahl. Es ist ein Root-privilegiertes Modul, dessen aktuelle Releases nicht unabhängig geprüft werden können, und genau das ist der genannte Grund, warum es ReZygisk gibt. Ob das für dich eine Rolle spielt, ist eine Abwägungssache, kein technischer Mangel.

Schritt 2: Integrity und Verstecken als Entscheidungsbaum

Die wichtigste Korrektur zur vorherigen Version dieser Anleitung:

Play Integrity zu bestehen und Root vor einer App zu verstecken sind zwei verschiedene Probleme.

Nutzer bestehen regelmäßig jedes Integrity-Urteil und trotzdem verweigert Google Wallet oder eine bestimmte Bank das Gerät, weil einzelne Apps über die Play-Integrity-API hinaus noch andere Signale prüfen. Den ganzen Stack zu installieren, weil eine Anleitung ihn für unverzichtbar erklärt hat, führt dazu, dass man mit sechs Modulen endet, wo zwei gereicht hätten.

Geh es als Baum durch. Teste nach jedem Schritt.

Fang mit der DenyList an. In Magisk eingebaut, kein Download nötig. Füge die Apps hinzu, vor denen Root versteckt werden soll. Viele Apps hören hier schon auf, sich zu beschweren, und du bist fertig. Magisk 31.0 hat außerdem webview_zygote als DenyList-Unmount-Ziel ergänzt.

Immer noch erkannt? Füge ein Verstecken-Modul hinzu. Shamiko, aus der LSPosed-Release-Distribution, v1.2.5 Stand Juni 2025 mit Android-16- und 16K-Page-Fixes, kein neueres Release Stand 30. Oktober 2026. Beachte die kontraintuitive Anforderung: Shamiko braucht die DenyList-Durchsetzung abgeschaltet, während die Liste selbst befüllt bleibt. Lässt du die Durchsetzung an, deaktiviert das Shamiko. Das ist die mit Abstand häufigste Fehlkonfiguration in diesem ganzen Artikel. Auf KernelSU mit einem SUSFS-Kernel brauchst du Shamiko oft gar nicht, weil der Kernel diese Aufgabe schon übernimmt.

Scheitert gezielt ein Integrity-Urteil? Füge ein Play-Integrity-Modul hinzu. osm0sis/PlayIntegrityFork, v18 Stand August 2026, ist die direkte Fortsetzung des eingestellten Originals und der Nachfolger, auf den dessen eigener Autor verwiesen hat. KOWX712/PlayIntegrityFix ist ein weiterer gepflegter Fork derselben Linie, v4.9 Stand Oktober 2026. Installiere nicht zwei PIF-Forks gleichzeitig.

Nur bei einer konkreten Key-Attestation-Anforderung an Tricky Store denken. 5ec1cff/TrickyStore, Android 10+. Forks von beakthoven und qwq233 sind ebenfalls im Umlauf und das, worauf mehrere Tooling-Projekte inzwischen abzielen.

Um zu verwalten, auf welche Apps es angewendet wird: KOWX712/Tricky-Addon-Update-Target-List gibt Tricky Store eine richtige Oberfläche für Zielliste, Keybox und Sicherheitspatch-Handling. Es ist ein eigenständiges Projekt, und der Autor bittet darum, Issues nicht im Hauptprojekt einzureichen.

Quelloffene Alternativen zu Tricky Store gibt es inzwischen. beakthoven/TrickyStoreOSS ist eine GPL-3.0-Neufassung (v3.1.0, August 2026). JingMatrix/TEESimulator ist ein GPL-3.0-Software-KeyMint, das im Keystore-Daemon läuft (v4.0, August 2026, Android 10+, nur 64-Bit-Geräte). qwq233/OhMyKeymint ist eine vollständige Keystore-Neuimplementierung, die näher am Stock-AOSP aussehen soll (Android 12+, Preview-Builds). Nutze genau eines. Keines davon liefert eine funktionierende Keybox mit, und wir verweisen weiterhin auf keine.

Drei Dinge, die andere Anleitungen dir nicht sagen

Tricky Store ist seit v1.1.0 closed source. Der Maintainer hat es wegen Missbrauchsbedenken geschlossen. Zusammen mit der Zygisk-Next-Lizenzänderung sind damit die beiden mächtigsten Tools dieser Kategorie nicht mehr überprüfbare Binärdateien, die als Root laufen. Das letzte Release war 1.4.1 im November 2025. Gut zu wissen, bevor du sie installierst, nicht danach. Quelloffene Neufassungen gibt es inzwischen, siehe unten, auch wenn sie neuer und weniger erprobt sind.

Tricky Store liefert keine funktionierende Keybox mit. Es liefert eine AOSP-Keybox, die für Attestation nicht gültig ist. Anleitungen, die sagen „Tricky Store installieren, starke Integrity bekommen", überspringen das komplett. Keyboxes werden außerdem gesperrt, und dann hört dein Setup still auf zu funktionieren. Wir verteilen keine Keyboxes und wären vorsichtig gegenüber jedem, der das tut.

Software-gestützte Geräte-Integrity wurde 2026 deutlich schwieriger. Anfang des Jahres wurde eine große Welle von Geräte-Fingerprints blockiert, und das wichtigste Community-Repository, das diese Sammlung pflegte, wurde von seinem Besitzer archiviert, der sagte, es gebe keine funktionierenden Fingerprints mehr für die gängigsten Architekturkombinationen. Fingerprint-Ansätze haben nicht aufgehört zu funktionieren, aber das Angebot ist nicht mehr, was es war.

Ehrlich gesagt: grundlegende Urteile sind weitgehend erreichbar, Geräte-Integrity braucht mehr Aufwand als früher, und starke Integrity auf einem entsperrten Bootloader ist wirklich schwierig. Manche Apps verweigern trotzdem. Wir veröffentlichen keine Erfolgsquote, weil sie innerhalb von Wochen falsch wäre.

Möchtest du das einmal korrekt eingerichtet haben, statt eine Woche lang Kombinationen zu testen? Schick uns dein Gerät, die Android-Version, die Root-Methode und die Apps, die laufen sollen. Wir richten es remote ein und sagen dir vorab, welche deiner Apps realistisch erreichbar sind. Kostenlose Diagnose beim Rooting-Service.

Wenn du um Hilfe bitten musst

Integrity-Verhalten ändert sich ständig, deshalb ist „funktioniert dieser Stack mit meiner Bank" ohne Details nicht zu beantworten. Wenn du jemanden fragst, uns eingeschlossen, schick das mit:

Gerät und genaues Modell:
Android-Version und Build:
Sicherheitspatch-Stand:
Root-Manager und Version:
Zygisk-Implementierung:
Installierte Module, mit Versionen:
Play-Integrity-Urteil:
App und Version, die scheitert:
Was genau angezeigt wird:

Das macht aus einer Frage, die niemand beantworten kann, eine, die jemand beantworten kann. Wir haben die anonymen App-Kompatibilitäts-Anekdoten aus der vorherigen Version dieser Anleitung entfernt, aus demselben Grund: Ihnen fehlten all diese Details, also waren sie nicht nachvollziehbar.

Schritt 3: die Xposed-Ebene

Das ursprüngliche LSPosed-Projekt hat seit Oktober 2023 kein Release und seit Januar 2024 keinen Commit auf master mehr, seine Releases zielten auf Android 8.1 bis 14. Der falsche Ausgangspunkt für ein modernes Gerät.

JingMatrix/LSPosed ist der gepflegte Fork, den die meisten nutzen, und er lebt jetzt im Repository JingMatrix/Vector (die alte URL leitet dorthin um). Vector hält die API-Konsistenz mit dem ursprünglichen Xposed, während es die Interna neu schreibt, mit Unterstützung bis Android 16 und 17 sowie 16K-Page-Geräten. Die Releases werden derzeit als Canary-Pre-Release-Builds veröffentlicht (canary-3114 am 26. Oktober 2026), keine getaggten Stable-Versionen, also die Release-Notes vor dem Update lesen.

JingMatrix/LSPatch ist der rootless Weg (Canary-Builds, wie Vector). Es bettet das Framework in eine App ein, indem es die APK dieser App patcht. Kein Root, kein Zygisk. Gut zu wissen, wenn du das Verhalten eines einzelnen Xposed-Moduls willst und sonst nichts.

ReLSPosed, ein weiterer Fork, der im Umlauf war, wurde im Februar 2026 vom Besitzer archiviert. Prüfe Daten, bevor du einem Fork vertraust.

Hide My Applist (Dr-TSNG/Hide-My-Applist) fängt das Scannen von App-Listen ab, das manche Apps nutzen, um Root-Manager aufzuspüren. Die Entwicklung war eine Weile ausgesetzt, brachte aber im August 2026 v3.8.3 heraus. Behandle es als gelegentlich gepflegt und prüfe das Release-Datum, bevor du dich darauf verlässt.

Xposed-Module selbst haben dasselbe Problem. Eines, das zwei Jahre lang nicht angefasst wurde, funktioniert auf Android 15 oder 16 vermutlich nicht, egal was der Thread behauptet.

Schritt 4: die verifizierte Liste

Gruppiert nach dem, was man tatsächlich will. Jeder Link führt zum eigenen Repository des Maintainers. Alles funktioniert mit Magisk, sofern nicht anders vermerkt.

Werbe- und Tracker-Blocker

Nutze genau einen Hosts-Blocker. Zwei, oder einen plus AdAways Root-Modus, bedeutet zwei Dinge, die um dieselbe Datei konkurrieren. Aggressive Listen brechen auch legitime App-Funktionen, also starte mit einem Standardprofil und erweitere nur bei konkretem Bedarf.

Zur Einordnung: Hosts-Blocking stoppt Domain-Auflösungen. Es tut nichts gegen Werbung, die von derselben Domain wie der Inhalt ausgeliefert wird. Androids Private-DNS-Einstellung bringt viel davon, ganz ohne Root.

Akku und Strom

ACC ist der ehrliche Ersatz für die vagen „Akkuverwaltung"-Einträge, die auf den meisten Listen ohne zugehöriges Repository auftauchen. Nutze das eigene Erkennungs-Tooling, statt den Lade-Schalter eines anderen Handys zu kopieren.

Gaming und Scheduling

Pro Spiel konfigurieren statt global. Gewinne hängen von Gerät, Kernel und Spiel ab, und die Demo-Videos übertreiben sie. Nicht mit einem weiteren Scheduler-Modul stapeln.

Oberfläche und Theming

Änderungen immer nur gruppenweise anwenden. SystemUI-Abstürze und Bootloops nach nicht unterstützten ROM- und Update-Kombinationen sind ein bekanntes Muster bei Theming-Modulen. Overlays vor einem größeren Systemupdate zurücksetzen.

Nützliches

Entwicklung und Sicherheitstests

Diese erweitern die Vertrauensgrenze deines Geräts. Sie existieren für Traffic-Debugging und Sicherheitsforschung und sind auf einem täglich genutzten Gerät keine gute Idee. Test-CAs nach Gebrauch entfernen. Keines der beiden hebelt Certificate Pinning aus.

Alternative Integrity-Toolkits

Integrity-Box (MeowDump/Integrity-Box) bündelt Integrity- und Umgebungsverwaltung hinter einer eigenen Oberfläche. PlayIntegrityFix-NEXT (EricInacio01/PlayIntegrityFix-NEXT) war ein experimenteller Fork, der Android 10 bis 16 abdeckte. Sein Besitzer archivierte es im Oktober 2025 nach dem v3.0-Release, also kein neues Setup mehr darauf aufbauen. Integrity-Box erscheint sehr häufig (v46 am 29. Oktober 2026), was zwei Seiten hat: schnelle Fixes, und ein bewegliches Ziel.

Beide überschneiden sich mit PlayIntegrityFork. Behandle sie als alternative Stacks, nicht als Ergänzung. Sich überschneidende Integrity-Tools erzeugen Konflikte, die mühsam zu diagnostizieren sind.

Verstecken auf Kernel-Ebene, nur KernelSU-Familie

SUSFS liegt bei gitlab.com/simonpunk/susfs4ksu mit einem begleitenden Modul bei sidex15/susfs4ksu-module. Es braucht einen Kernel mit eingepatchtem SUSFS, ist also eine Option für KernelSU, KernelSU Next oder SukiSU Ultra. Nicht verfügbar auf Magisk oder APatch.

Risikostufen

Nicht jedes Modul trägt dasselbe Risiko.

Wo du Module jetzt herbekommst

Da das eingebaute Repository weg ist:

1. Die eigene GitHub-Releases-Seite des Projekts. Die richtige Quelle für alles oben, und wohin jeder Link hier führt. Lade das .zip-Asset herunter, nicht das Quellarchiv.
2. Magisk-Modules-Alt-Repo, das Community-Repository, das neue Einreichungen annimmt.
3. MMRL, eine Modul-Manager-App, die Magisk-, KernelSU- und APatch-Module verwaltet, falls dir Stöbern lieber ist als manuelles Herunterladen.

Zum Installieren: Root-Manager öffnen, zu Module gehen, auf „Aus Speicher installieren" tippen, die ZIP wählen, neu starten.

Wir hosten keine Modul-Binärdateien und wären vorsichtig gegenüber jedem, der das tut. Lade vom Projekt herunter, nicht von einem Mirror, einem gekürzten Link oder einer Telegram-Datei.

Wie du ein Modul prüfst

Root-Module laufen mit vollen Rechten. Das verdient entsprechende Sorgfalt:

• Ist die Quelle einsehbar? Kein Repository, keine Installation. Das allein schließt schon viel aus.
• Wann war das letzte Release? Zwei Jahre unangefasst auf einem sich schnell bewegenden Ziel ist ein Risiko.
• Antwortet der Maintainer auf Issues? Monatelanges Schweigen ist ein Warnsignal.
• Nennt die Dokumentation die Kompatibilität? Android-Version, Root-Manager, bekannte Konflikte.
• Läuft es bei jemandem auf deiner Android-Version und deinem Root-Manager? Nicht auf dem Gerät, für das es 2023 geschrieben wurde.
• Verlangt es, etwas zu schwächen? Alles, das verlangt, SELinux zu deaktivieren, verdient einen genauen Blick.

Aus einem Bootloop herauskommen

Halte das bereit, bevor du es brauchst. In Reihenfolge der Vorzugswürdigkeit:

1. Abgesicherter Modus. Magisk deaktiviert alle Module, wenn es einen Boot im abgesicherten Modus erkennt. Im abgesicherten Modus starten, dann normal neu starten, und du bekommst ein laufendes System mit allem ausgeschaltet, sodass du den Übeltäter aus der App entfernen kannst. KernelSU macht dasselbe. Die Tastenkombination variiert je nach Gerät, also einmal üben, solange noch alles funktioniert.

2. Der Entfernen-Befehl. Wenn ein Computer das Gerät sieht, während es zu booten versucht, dokumentiert Magisk das hier:

adb wait-for-device shell magisk --remove-modules

Es entfernt alle Module und startet neu.

3. Ein einzelnes Modul per Shell deaktivieren. Eine disable-Datei im Ordner eines Moduls unter /data/adb/modules/ zu erstellen, schaltet nur dieses eine aus.

4. Das Stock-Boot-Image wiederherstellen. Der Rückfallplan, und der Grund, eins aufzubewahren. Lies zuerst die Warnung unten.

Die Boot-Image-Falle

Magisks eigene Dokumentation warnt, dass die Wiederherstellung von Partitionen geräteabhängig ist, und rät insbesondere Samsung-Nutzern davon ab, leichtfertig boot, init_boot, recovery oder vbmeta wiederherzustellen. Allgemeine Fastboot-Ratschläge lassen sich nicht herstellerübergreifend übertragen. APatch-Nutzer sollten außerdem beachten, dass es boot patcht, nicht init_boot.

Folge der Prozedur für dein genaues Gerät. Ist ein Flash schon schiefgegangen, erst diagnostizieren, bevor du erneut flashst, und bootet das Gerät gar nicht mehr, zuerst herausfinden, in welchem Zustand es ist.

Was auch immer du tust, fang nicht an zu löschen. Die Reihenfolge der Schritte zählt, und ein Zurücksetzen auf Werkseinstellungen zerstört deine Verschlüsselungsschlüssel zusammen mit deinen Daten.

Weiterführende Links: Magisk vs. KernelSU vs. APatch · SafetyNet und Play Integrity mit Root · Magisk 2026: was sich geändert hat · Magisk-Flash fehlgeschlagen · OTA-Update auf gerootetem Android fehlgeschlagen · Android-Debloating-Anleitung

Quellen: Das jeweilige GitHub- oder GitLab-Repository, direkt verlinkt. Offizielle Magisk-Dokumentation, FAQ und Release-Notes. Offizielle APatch- und KernelSU-Dokumentation. Modul-Status gegen Repository-Aktivität und Maintainer-Aussagen zum oben genannten Datum verifiziert.

Zuletzt verifiziert: 30. Oktober 2026. Dieses Ökosystem bewegt sich schnell. Die hier gelisteten Projekte waren zum Zeitpunkt der Verifizierung aktiv, und jedes kann ohne Vorwarnung eingestellt, geforkt oder abgelöst werden. Prüfe das verlinkte Repository vor der Installation und behandle Kompatibilität als geräteabhängig.