SafetyNet vs. Play Integrity API: so bestehst du sie mit Root (2026)

Die SafetyNet API, die die Android-Root-Community ein Jahrzehnt lang kannte, hat Google Anfang 2024 offiziell eingestellt und durch die Play Integrity API ersetzt. Jeder Guide aus der Zeit vor 2024 ist damit veraltet, und in alten Forenthreads hält sich viel Fehlinformation. Dieser Guide ist die aktuelle, praxisnahe Anleitung für 2026: was sich geändert hat, was die drei Play-Integrity-Verdicts wirklich bedeuten, welche Bypass-Tools 2026 funktionieren und eine Schritt-für-Schritt-Einrichtung samt der konkreten Magisk-Befehle. Er richtet sich an fortgeschrittene Nutzer, die bereits ein gerootetes Gerät haben und Banking- und Zahlungs-Apps zum Laufen bringen müssen.

Kurze Geschichte: von SafetyNet zu Play Integrity

SafetyNet (2014-2024) war Googles API zur Geräte-Attestierung. Sie lieferte zwei boolesche Felder: ctsProfileMatch (passt dieses Gerät zu einem bekannten Profil der Compatibility Test Suite?) und basicIntegrity (besteht das Gerät grundlegende Integritätsprüfungen wie den Zustand „Bootloader gesperrt“?). Banking-Apps riefen sie über die Google-Play-Dienste auf, bekamen die beiden Boolean-Werte und verweigerten den Dienst, wenn einer davon false war. Die Bypass-Methoden entwickelten sich über das Jahrzehnt weiter: zuerst MagiskHide, dann Zygisk + DenyList, nachdem MagiskHide mit Magisk 24 eingestellt wurde, und schließlich Shamiko zusätzlich für stärkeres Verbergen.

Die Play Integrity API (seit 2023) ist der offizielle Nachfolger. Der Zeitplan der Abkündigung:

• Juni 2023: Die Play Integrity API startet als bevorzugter Ersatz
• Mitte 2023 bis Anfang 2024: Apps beginnen, von SafetyNet auf Play Integrity umzusteigen
• Januar 2024: SafetyNet wird offiziell abgekündigt; neue API-Antworten sind nicht mehr garantiert
• Bis Mitte 2026: Fast alle großen Banking- und Zahlungs-Apps verwenden ausschließlich Play Integrity

Play Integrity liefert drei Verdicts statt zwei boolescher Werte und nutzt für die strengste Stufe hardwaregestützte Key Attestation. Das macht den Bypass mit reinen Software-Methoden grundsätzlich schwerer.

Die drei Play-Integrity-Verdicts erklärt

Jede Play-Integrity-Prüfung liefert drei boolesche Werte:

MEETS_DEVICE_INTEGRITY

Die Basisstufe. Sie bedeutet: Das Gerät läuft mit unverändertem Android, hat die Google-Play-Dienste installiert und besteht grundlegende Kompatibilitätsprüfungen. Auf gerooteten Geräten umgehbar mit aktuellen Tools (Magisk + Zygisk + DenyList + Shamiko + Play-Integrity-Fix-Modul). Etwa 60 Prozent der Apps verlangen dieses Verdict für den normalen Betrieb.

MEETS_BASIC_INTEGRITY

Eine strengere Prüfung mit zusätzlicher Validierung der Umgebung: Integrität der Systemdateien, erwarteter Zustand der Google-Play-Dienste, bestimmte Prüfungen des Debugging-Zustands. Auf gerooteten Geräten meist umgehbar, aber empfindlicher gegenüber der Modulkonfiguration. Etwa 30 Prozent der Apps verlangen dieses Verdict zusätzlich zu DEVICE_INTEGRITY. Die meisten Banking-Apps verlangen beide.

MEETS_STRONG_INTEGRITY

Die höchste Stufe. Sie nutzt hardwaregestützte Key Attestation: Das TEE (Trusted Execution Environment) des Geräts signiert eine Antwort, die sich bis zum Root-Zertifikat des Geräteherstellers zurückverfolgen lässt. Das funktioniert auch bei gesperrtem Bootloader, weil die Schlüssel durch das Secure Element geschützt sind. Mit aktuellen Software-Methoden auf einem Gerät mit entsperrtem Bootloader nicht umgehbar, weil das Entsperren die Verified-Boot-Kette bricht, auf die sich die TEE-Schlüssel stützen.

Etwa 10 bis 20 Prozent der Apps verlangen STRONG_INTEGRITY:

• Google Wallet für kontaktloses Bezahlen in manchen Regionen
• Mehrere Neobanken (Revolut, Wise, N26 in manchen Regionen)
• Bestimmte Behörden-Apps für Ausweise (digitale Pässe, Wähler-ID)
• Gesundheits-Apps mit strengen Compliance-Anforderungen
• Einige vom Arbeitgeber bereitgestellte, per MDM geschützte Business-Apps

Wenn deine wichtigen Apps STRONG_INTEGRITY verlangen, ist Root mit ihnen nicht vereinbar, und kein aktueller Workaround ändert das.

Bypass-Tools: Magisk Hide vs. Shamiko vs. TrickyStore

Drei Haupt-Tools arbeiten zusammen, um 2026 die Play Integrity auf gerooteten Geräten zu umgehen:

Schritt für Schritt: Play Integrity für einfache Banking-Apps bestehen

Voraussetzung ist, dass du bereits Folgendes hast:

• Entsperrten Bootloader
• Magisk, installiert über ein gepatchtes boot.img
• Funktionierendes Root, in Magisk Manager geprüft

Falls du das noch nicht hast, lies zuerst unseren Guide zum Entsperren des Bootloaders und Magisk vs. KernelSU vs. APatch.

Schritt 1: Zygisk in Magisk aktivieren

Öffne die Magisk-App → Settings (Zahnrad-Symbol) → aktiviere den Schalter Zygisk. Starte neu.

Gehe nach dem Neustart zurück zu den Magisk-Settings und aktiviere Enforce DenyList.

Schritt 2: Shamiko installieren

Lade das aktuelle Shamiko-Zip von den offiziellen Releases von LSPosed/LSPosed auf GitHub herunter. Tippe in der Magisk-App im Tab „Modules“ auf das +-Symbol, wähle das Shamiko-Zip aus und installiere es. Starte neu.

Prüfe nach dem Neustart, ob Shamiko geladen ist: In der Magisk-App im Tab „Modules“ sollte Shamiko aufgeführt und aktiviert sein.

Schritt 3: Play-Integrity-Fix-Modul installieren

Lade das aktuelle PIF-Zip von den GitHub-Releases von chiteroman/PlayIntegrityFork herunter (oder von dem Fork, der gerade gepflegt wird; aktuelle Empfehlungen findest du in den Threads der XDA Recognized Developers).

Magisk-App → Modules → + → PIF-Zip installieren → neu starten.

Schritt 4: PIF-Fingerprint auf einen aktualisieren, der aktuell besteht

Der Fingerprint in PIF muss zu einem bekannten Gerät passen, das Play Integrity aktuell besteht. Das PIF-Modul enthält ein Autoupdate-Skript. Öffne eine Terminal-App (Termux genügt) und führe aus:

su -c sh /data/adb/modules/playintegrityfix/action.sh

Das lädt den neuesten Fingerprint, der die Prüfung besteht, aus der Community-Liste und wendet ihn an. Starte neu.

Schritt 5: DenyList für deine Apps konfigurieren

Magisk-App → Configure DenyList → suche jede Banking- und Zahlungs-App sowie jede andere App, die Play Integrity prüft und die du nutzen willst. Tippe bei jeder App auf den Schalter, um das Verbergen zu aktivieren. Einträge für Unterprozesse schalten sich meist automatisch mit.

Typische Apps zum Hinzufügen:

• Deine Haupt-Banking-App (HDFC, SBI, Bank of America, Lloyds usw.)
• Mobile-Money-Apps (bKash, GCash, M-Pesa, JazzCash)
• Zahlungs-Apps (Google Pay, PayPal, Venmo, Cash App)
• Broker-Apps (Robinhood, Zerodha, Groww)
• Behörden-Apps (DigiLocker, Aadhaar, NHS app)
• Streaming-Apps mit DRM (Netflix, Disney+, Amazon Prime; sie prüfen Play Integrity für HD/4K)

Schritt 6: Mit Play Integrity API Checker prüfen

Installiere den Play Integrity API Checker aus dem Play Store (es gibt mehrere Versionen; probiere die von gkkang oder die vom LSPosed-Team gepflegte).

Öffne ihn und tippe auf Check. Achte auf:

• MEETS_DEVICE_INTEGRITY: sollte true sein
• MEETS_BASIC_INTEGRITY: sollte true sein
• MEETS_STRONG_INTEGRITY: ist bei einem Gerät mit entsperrtem Bootloader false, das ist normal

Liefern DEVICE und BASIC beide true, funktioniert der Bypass auf Verdict-Ebene. Die meisten Banking- und Zahlungs-Apps laufen jetzt normal.

Schritt 7: Jede Banking-App einzeln testen

Öffne jede App einzeln. Prüfe, ob sie über den Startbildschirm hinaus startet und dich anmelden lässt. Wenn eine App scheitert:

1. Prüfe, ob die App in der DenyList aktiviert ist
2. Führe den PIF-Autoupdate-Befehl erneut aus, um den Fingerprint zu aktualisieren
3. Neu starten
4. Scheitert sie weiter, nutzt genau diese App womöglich zusätzliche Erkennung jenseits von Play Integrity. Probiere TrickyStore als zusätzliche Ebene oder akzeptiere, dass die App mit deinem aktuellen Root-Setup nicht kompatibel ist

Wenn Apps trotz bestandenem Verdict weiter scheitern

Manche Apps nutzen zusätzliche Erkennungswege jenseits der offiziellen Play Integrity API:

• Direktes Scannen von Dateien: Sie suchen nach /system/bin/su, Magisk-Binärpfaden oder bekannten Installationspfaden von Modulen. Workaround: das MagiskHide-ähnliche Verbergen von Dateien in Magisk aktivieren (in neueren Magisk-Versionen eingebaut).
• Prüfung des Prozess-Namespace: Sie prüfen /proc/self/status und Ähnliches auf Signaturen von Zygisk-Hooks. Workaround: Shamiko deckt die meisten Fälle ab.
• TEE-Attestierungs-Challenges unabhängig von Play Integrity. Workaround: TrickyStore bei manchen Apps; bei anderen unmöglich.
• App-spezifische Sperrlisten, die der App-Entwickler pflegt und die bekannte Root-Paketnamen enthalten. Workaround: die Magisk-App über Settings → Hide the Magisk app umbenennen und ihr einen Namen geben, der nicht nach Magisk aussieht.

Stand der Banking-Apps je Region: was auf gerootetem Android aktuell funktioniert

Das Verhalten von Banking-Apps unterscheidet sich je nach Region stark, weil jede Bank selbst festlegt, wie streng sie die Integrität prüft. Grundlage sind Kundenberichte aus den Märkten BD/IN/PK/UK bis 2026:

Bangladesch

• bKash: funktioniert bei den meisten Nutzern mit Magisk + Shamiko + PIF; nach Google-Updates ist gelegentlich ein Fingerprint-Update nötig
• Nagad: funktioniert mit demselben Stack; etwas empfindlicher gegenüber der Aktualität des Fingerprints
• Rocket (DBBL): funktioniert mit dem Standard-Stack
• Apps von City Bank, BRAC Bank, EBL und Dutch-Bangla Bank: die meisten funktionieren mit dem Standard-Stack; nach jedem Play-Integrity-Update prüfen
• Bankspezifisches kontaktloses Bezahlen: verlangt in der Regel STRONG_INTEGRITY; auf gerooteten Geräten nicht umgehbar

Indien

• Google Pay (Tez): UPI funktioniert mit dem Standard-Stack; kontaktloses Bezahlen (in unterstützten Regionen) verlangt STRONG_INTEGRITY
• PhonePe, Paytm: UPI funktioniert mit dem Standard-Stack
• HDFC, ICICI, SBI YONO, Axis Mobile: die meisten funktionieren; HDFC und Axis sind etwas strenger und brauchen für bestimmte Funktionen eventuell TrickyStore
• Broker-Apps (Zerodha Kite, Groww, Upstox): funktionieren mit dem Standard-Stack
• Aadhaar-App mAadhaar: funktioniert für die meisten Funktionen; biometrische Funktionen brauchen eventuell eine zusätzliche Konfiguration zum Verbergen

Pakistan

• JazzCash, Easypaisa: beide funktionieren bei den meisten Nutzern mit dem Standard-Stack
• HBL Mobile, UBL Digital, Meezan Bank Mobile: die meisten funktionieren; Meezan ist von den dreien die strengste
• NayaPay, SadaPay (Neobank): unterschiedlich; prüfe, bevor du dich bei diesen auf Root verlässt

Großbritannien und EU

• Die meisten Apps der großen Banken (Lloyds, Barclays, HSBC, Santander, NatWest): funktionieren Stand Mitte 2026 mit dem Standard-Stack
• Neobanken (Revolut, Wise, N26, Monzo): Revolut und Wise sind notorisch streng und verlangen in manchen Abläufen häufig STRONG_INTEGRITY; Monzo und Starling sind meist nachgiebiger
• Entsprechungen zu Apple/Google Pay (kontaktloses Bezahlen): verlangen STRONG_INTEGRITY; nicht umgehbar

Diese Liste gibt den Stand zum Zeitpunkt des Schreibens wieder und ändert sich regelmäßig. Teste immer deine konkreten Apps, bevor du dich bei zeitkritischen Finanzgeschäften auf Root verlässt.

Was STRONG_INTEGRITY auf TEE-Ebene wirklich bedeutet

Kurzer technischer Hintergrund für fortgeschrittene Nutzer, warum sich STRONG_INTEGRITY auf Geräten mit entsperrtem Bootloader grundsätzlich nicht umgehen lässt.

Moderne Android-Geräte enthalten ein Trusted Execution Environment (TEE): einen separaten, sicheren Prozessor mit eigenem Speicher und eigenem Betriebssystem, isoliert vom Haupt-Android-System. Das TEE hält gerätespezifische kryptografische Schlüssel, die im Werk eingebracht und von der Root-Zertifizierungsstelle des Herstellers signiert wurden.

Fordert eine App STRONG_INTEGRITY an, läuft die Anfrage durch das TEE, das eine Antwort mit diesen im Werk eingebrachten Schlüsseln signiert. Die Antwort enthält den aktuellen Verified-Boot-Zustand: eine Hash-Kette, die belegt, dass der Bootloader gesperrt ist und die Partitionen boot, system und vendor den vom Hersteller signierten Erwartungen entsprechen.

Wenn du den Bootloader entsperrst, setzt das TEE seinen Verified-Boot-Zustand auf „yellow“ (vom Nutzer installierte Schlüssel) oder „orange“ (kein Verified Boot). Das TEE signiert STRONG_INTEGRITY-Antworten weiterhin, aber die Antwort enthält ausdrücklich den entsperrten Zustand. Apps, die STRONG_INTEGRITY verlangen, prüfen dieses Feld und verweigern den Betrieb, sobald der Zustand etwas anderes als „green“ ist (gesperrter Bootloader, vom Hersteller signierte Boot-Kette).

Software kann das nicht fälschen, weil das TEE mit Schlüsseln signiert, auf die das Haupt-Betriebssystem keinen Zugriff hat. TrickyStore kann den Keystore-Aufruf abfangen, bevor er das TEE erreicht, und eine vorab aufgezeichnete „gute“ Antwort eines ähnlichen Geräts einsetzen. Das funktioniert bei manchen Apps, die den Hardware-Ursprung der Antwort nicht richtig prüfen. Apps, die ihn prüfen (die strengen), erkennen den Austausch aber.

Die einzigen verlässlichen Wege, STRONG_INTEGRITY zu bestehen:

• Ein boot.img der Stock-Firmware ausführen und den Bootloader wieder sperren. Manche Geräte (Pixel, bestimmte OnePlus-Modelle) unterstützen das erneute Sperren des Bootloaders nach dem Flashen vom Hersteller signierter Images. Das stellt STRONG_INTEGRITY wieder her, aber du verlierst Root.
• Ein zweites Gerät ohne Root nutzen für die wenigen Apps, die STRONG_INTEGRITY verlangen.

Es gibt keine versteckte dritte Möglichkeit. Das TEE-Design soll genau das verhindern.

Was wir nie empfehlen

• Mehrere Play-Integrity-Bypass-Module gleichzeitig ohne konkreten Grund laufen lassen: Sie kollidieren oft und machen mehr Apps kaputt, als sie reparieren.
• Beliebige PIF-Forks aus unbekannten Quellen verwenden. Halte dich an den gepflegten Haupt-Fork und schau in den XDA-Threads nach der aktuellen Empfehlung.
• Sich bei hochwertigen Finanztransaktionen auf den Bypass verlassen. Nutze ein Ersatzgerät ohne Root für Beträge, die du nicht verlieren kannst, und lies die AGB deiner Bank zur Haftung bei Betrug auf gerooteten Geräten.
• Root für den Play Store selbst aktivieren. Der Play Store muss nicht in der DenyList stehen; das kann Funktionen des Play Store ohne Nutzen kaputt machen.

Wann du einen Profi holen solltest

Wenn eine bestimmte Banking-App nach einer Root-Installation nicht mehr funktioniert und du den Standard-Stack ausprobiert hast, schreib uns auf WhatsApp oder Telegram. Für die meisten großen Banken in BD, IN, PK, UK, den USA und der EU haben wir geprüfte, bewährte Setups und bekommen eine App meist in einer Remote-Sitzung von 30 bis 60 Minuten zum Laufen. Was enthalten ist, steht bei unserem Android-Root-Service.

Mehr zu DenyList und Shamiko auf Modulebene steht in unserem Guide zu Magisk-Modulen: Er behandelt den aktuellen Stack zum Verbergen bei Play Integrity und zeigt, welche Forks noch gepflegt werden.