Guide Advanced 11 min read

SafetyNet vs Play Integrity API — Pass It With Root (2026)

Name: Droid Rooter
Price range: $$

SafetyNet retired in 2024 — Play Integrity API replaced it. Here's how to pass MEETS_DEVICE_INTEGRITY and basic banking apps with Magisk + Shamiko in 2026.

By Alex Dutrow | Published May 2, 2026

Table of Contents

The SafetyNet API that Android rooting community knew for a decade was formally retired by Google at the start of 2024 and replaced with Play Integrity API. Every guide written before 2024 is now outdated, and a lot of misinformation persists in old forum threads. This guide is the current, practical, 2026 walkthrough — what changed, what the three Play Integrity verdicts actually mean, which bypass tools work in 2026, and step-by-step setup instructions including the specific Magisk commands. Targeted at advanced users who already have a rooted device and need to make banking and payment apps work.

A short history: SafetyNet to Play Integrity

SafetyNet (2014-2024) was Google’s device attestation API. It returned two boolean fields — ctsProfileMatch (does this device match a known Compatibility Test Suite profile?) and basicIntegrity (does this device pass basic integrity checks like bootloader-locked state?). Banking apps would call it via Google Play Services, get the two booleans, and refuse to operate if either was false. Bypass methods evolved over the decade — MagiskHide initially, then Zygisk + DenyList after MagiskHide was retired in Magisk 24, then Shamiko on top for stronger hiding.

Play Integrity API (2023-present) is the official replacement. The deprecation timeline:

June 2023 — Play Integrity API launched as preferred replacement
Mid-2023 to early 2024 — Apps began migrating from SafetyNet to Play Integrity
January 2024 — SafetyNet formally deprecated; new API responses no longer guaranteed
By mid-2026 — Almost all major banking and payment apps now use Play Integrity exclusively

Play Integrity returns three verdicts instead of two booleans, and uses hardware key attestation for the strictest level — making it fundamentally harder to bypass with software-only methods.

The three Play Integrity verdicts explained

Every Play Integrity check returns three boolean values:

MEETS_DEVICE_INTEGRITY

The base level. Means the device is running unmodified Android, has Google Play Services installed, and passes basic compatibility checks. Bypassable on rooted devices with current tools (Magisk + Zygisk + DenyList + Shamiko + Play Integrity Fix module). About 60 percent of apps require this verdict to operate normally.

MEETS_BASIC_INTEGRITY

A stricter check that includes some additional environment validation — system file integrity, expected Google Play Services state, certain debugging-state checks. Mostly bypassable on rooted devices but more sensitive to module configuration. About 30 percent of apps require this verdict in addition to DEVICE_INTEGRITY. Most banking apps require both.

MEETS_STRONG_INTEGRITY

The hardest level. Uses hardware-backed key attestation — the device’s TEE (Trusted Execution Environment) signs a response that can be verified back to the device manufacturer’s root certificate. This works even when the bootloader is locked because the keys are protected by the secure element. Cannot be bypassed by current software methods on a bootloader-unlocked device because the unlock breaks the verified-boot chain that the TEE keys rely on.

About 10 to 20 percent of apps require STRONG_INTEGRITY:

Google Wallet tap-to-pay in some regions
Several neobanks (Revolut, Wise, N26 in some regions)
Certain government ID apps (digital passports, voter ID)
Healthcare apps with strict compliance requirements
Some employer-issued MDM-protected work apps

If your essential apps require STRONG_INTEGRITY, root is incompatible with them and no current workaround changes that.

Bypass tooling — Magisk Hide vs Shamiko vs TrickyStore

Three primary tools work together for current-2026 Play Integrity bypass on rooted devices:

Current Play Integrity bypass tooling for Android root in 2026. Magisk + Zygisk + DenyList + Shamiko + PIF is the standard stack; TrickyStore is added only for specific app failures.
Tool	What it does	Bypass scope	Setup difficulty	Detection risk
Magisk DenyList (built-in)	Hides root state from listed apps via Zygisk hooks	MEETS_DEVICE_INTEGRITY only, on its own	Easy — built into Magisk	Low for basic apps; insufficient for serious banking detection
Shamiko (LSPosed module)	Adds aggressive hiding on top of DenyList — hides Zygisk itself, hides app processes from system queries	MEETS_DEVICE + BASIC for ~80% of banking apps when paired with PIF	Easy — install via Magisk modules	Low; works invisibly with DenyList
Play Integrity Fix (PIF)	Spoofs the device fingerprint sent to Google's attestation servers to one known to currently pass	Required for any verdict bypass to work in 2026	Easy — install module + run autoupdate command	Medium; depends on fingerprint freshness
TrickyStore	Spoofs hardware key attestation responses at the keystore level; can pass apps that check key store consistency	Adds another 5-10% of stricter apps to the bypassable set	Hard — requires manual key list configuration per device	Higher; some apps detect TrickyStore-spoofed responses
Magisk Hide (legacy)	Removed from Magisk 24+ — replaced by DenyList + Zygisk	N/A — do not look for it in current Magisk	N/A	N/A

Step-by-step: pass Play Integrity for basic banking apps

Assumes you already have:

Bootloader unlocked
Magisk installed via patched boot.img
Working root verified in Magisk Manager

If you do not have those yet, see our bootloader unlock guide and Magisk vs KernelSU vs APatch first.

Step 1: Enable Zygisk in Magisk

Open Magisk app → Settings (gear icon) → enable Zygisk toggle. Reboot.

After reboot, return to Magisk Settings and enable Enforce DenyList.

Step 2: Install Shamiko

Download the latest Shamiko zip from the official LSPosed/LSPosed releases on GitHub. In Magisk app → Modules tab → tap the + icon → browse to the Shamiko zip → install. Reboot.

After reboot, verify Shamiko is loaded — Magisk app → Modules tab → Shamiko should be listed and enabled.

Step 3: Install Play Integrity Fix module

Download the latest PIF zip from the chiteroman/PlayIntegrityFork GitHub releases (or whichever fork is currently maintained — check the XDA Recognized Developer threads for current recommendations).

Magisk app → Modules → + → install the PIF zip → reboot.

Step 4: Update PIF fingerprint to a current passing one

The fingerprint inside PIF needs to match a known device that is currently passing Play Integrity. The PIF module includes an autoupdate script. Open a terminal app (Termux is fine) and run:

bash

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

This pulls the latest community-maintained passing fingerprint and applies it. Reboot.

Step 5: Configure DenyList for your apps

Magisk app → Configure DenyList → search for each banking, payment or Play Integrity-checking app you need to use. Tap the toggle next to each app to enable hiding. Sub-process entries usually toggle automatically.

Common apps to add:

Your primary banking app (HDFC, SBI, Bank of America, Lloyds, etc.)
Mobile money apps (bKash, GCash, M-Pesa, JazzCash)
Payment apps (Google Pay, PayPal, Venmo, Cash App)
Brokerage apps (Robinhood, Zerodha, Groww)
Government apps (DigiLocker, Aadhaar, NHS app)
Streaming apps with DRM (Netflix, Disney+, Amazon Prime — these check Play Integrity for HD/4K)

Step 6: Verify with Play Integrity API Checker

Install Play Integrity API Checker from the Play Store (multiple versions exist; try the one by gkkang or the one maintained by the LSPosed team).

Open it. Tap Check. Look for:

MEETS_DEVICE_INTEGRITY — should be true
MEETS_BASIC_INTEGRITY — should be true
MEETS_STRONG_INTEGRITY — will be false on a bootloader-unlocked device, expected

If both DEVICE and BASIC return true, the bypass is working at the verdict level. Most banking and payment apps will now operate normally.

Step 7: Test each banking app individually

Open each app one at a time. Confirm it launches past the splash screen and lets you log in. If any app fails:

Confirm the app is enabled in DenyList
Re-run the PIF autoupdate command to refresh the fingerprint
Reboot
If still failing, that specific app may use additional detection beyond Play Integrity — try TrickyStore as an additional layer, or accept that the app is incompatible with your current root setup

When apps still fail despite verdict passing

Some apps use additional detection vectors beyond the official Play Integrity API:

Direct file scanning — looking for /system/bin/su, Magisk binary paths, or known module install paths. Workaround: enable Magisk’s MagiskHide-equivalent file hiding (built into recent Magisk versions).
Process namespace inspection — checking /proc/self/status and similar for Zygisk hook signatures. Workaround: Shamiko handles most cases.
TEE attestation challenges independent of Play Integrity. Workaround: TrickyStore for some apps; impossible for others.
App-specific blocklists maintained by the app developer that include known root-related package names. Workaround: rename Magisk app via Settings → Hide the Magisk app, give it a non-Magisk-looking name.

Regional banking app status — what currently works on rooted Android

Banking app behaviour varies dramatically by region because each bank chooses its own integrity-check stringency. Based on customer reports across BD/IN/PK/UK markets through 2026:

Bangladesh

bKash — works with Magisk + Shamiko + PIF for most users; occasional fingerprint-update needed after Google updates
Nagad — works with the same stack; slightly more sensitive to fingerprint freshness
Rocket (DBBL) — works with the standard stack
City Bank, BRAC Bank, EBL, Dutch-Bangla Bank apps — most work with standard stack; check after each Play Integrity update
Bank-specific tap-to-pay — generally requires STRONG_INTEGRITY; not bypassable on rooted devices

India

Google Pay (Tez) — UPI works with standard stack; tap-to-pay (in supported regions) requires STRONG_INTEGRITY
PhonePe, Paytm — UPI works with standard stack
HDFC, ICICI, SBI YONO, Axis Mobile — most work; HDFC and Axis are slightly stricter and may need TrickyStore for certain features
Brokerage apps (Zerodha Kite, Groww, Upstox) — work with standard stack
Aadhaar mAadhaar app — works for most features; biometric features may require additional hiding configuration

Pakistan

JazzCash, Easypaisa — both work with standard stack for most users
HBL Mobile, UBL Digital, Meezan Bank Mobile — most work; Meezan is the strictest of the three
NayaPay, SadaPay (neobank) — variable; check before relying on root for these

UK and EU

Most high-street banking apps (Lloyds, Barclays, HSBC, Santander, NatWest) — work with the standard stack as of mid-2026
Neobanks (Revolut, Wise, N26, Monzo) — Revolut and Wise are notoriously strict and frequently require STRONG_INTEGRITY in some flows; Monzo and Starling are usually more lenient
Apple/Google tap-to-pay equivalents — require STRONG_INTEGRITY; not bypassable

This list reflects the situation at time of writing and changes regularly. Always test your specific apps before relying on root for time-critical financial use.

What STRONG_INTEGRITY actually involves at the TEE level

Quick technical context for advanced users on why STRONG_INTEGRITY is fundamentally unbypassable on bootloader-unlocked devices.

Modern Android devices include a Trusted Execution Environment (TEE) — a separate secure processor with its own memory and operating system, isolated from the main Android OS. The TEE holds device-unique cryptographic keys provisioned at the factory and signed by the manufacturer’s root certificate authority.

When an app requests STRONG_INTEGRITY, the request goes through the TEE, which signs a response using these factory-provisioned keys. The response includes the current verified-boot state — a hash chain that proves the bootloader is locked and the boot, system, and vendor partitions match the manufacturer’s signed expectations.

When you unlock the bootloader, the TEE updates its verified-boot state to “yellow” (user-installed keys) or “orange” (no verified boot). The TEE will still sign STRONG_INTEGRITY responses, but the response will explicitly include the unlocked state. Apps that require STRONG_INTEGRITY check this field and refuse to operate when the state is anything other than green (locked bootloader, manufacturer-signed boot chain).

Software bypass cannot fake this because the TEE signs with keys the main OS does not have access to. TrickyStore can intercept the keystore call before it reaches the TEE and substitute a pre-recorded “good” response from a similar device, which works for some apps that do not validate the response’s hardware origin properly — but apps that do validate (the strict ones) will detect the substitution.

The only reliable ways to pass STRONG_INTEGRITY:

Run a stock-firmware boot.img with bootloader re-locked. Some devices (Pixels, certain OnePlus models) support re-locking the bootloader after flashing manufacturer-signed images. This restores STRONG_INTEGRITY but loses root.
Use a secondary unrooted device for the small number of apps that require STRONG_INTEGRITY.

There is no hidden third option. The TEE design is specifically intended to prevent it.

Running multiple Play Integrity bypass modules simultaneously without specific reason — they often conflict and break more apps than they fix.
Using random PIF forks from unknown sources. Stick to the maintained mainline fork and check XDA threads for the current recommendation.
Relying on bypass for high-value financial transactions. Use an unrooted backup device for amounts you cannot afford to lose, and read your bank’s terms of service about rooted-device fraud liability.
Enabling root for the Play Store itself. Play Store does not need to be in DenyList; doing so can break Play Store features without benefit.

When to call a professional

If you have a specific banking app refusing to work after a root install and you have tried the standard stack — message us on WhatsApp or Telegram. We have reviewed-and-known-working setups for most major banks across BD, IN, PK, UK, US and EU markets and can usually get an app working in a 30 to 60 minute remote session. See our Android rooting service for what is included.

Frequently Asked Questions

What's the difference between SafetyNet and Play Integrity API?

SafetyNet was Google's previous device-attestation API used by banking and payment apps to detect rooted, modified, or emulated Android devices. Google formally retired SafetyNet at the start of 2024 and replaced it with Play Integrity API, which provides three integrity verdicts (DEVICE_INTEGRITY, BASIC_INTEGRITY, STRONG_INTEGRITY) instead of SafetyNet's single ctsProfileMatch + basicIntegrity pair. Play Integrity is harder to bypass with root because the STRONG_INTEGRITY verdict uses hardware key attestation that cannot be spoofed in software.

Can I pass Play Integrity API on a rooted Android in 2026?

MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY — yes, with Magisk + Zygisk + DenyList + Shamiko + Play Integrity Fix module configured correctly, around 80 to 90 percent of banking and payment apps work normally on a rooted device. MEETS_STRONG_INTEGRITY — almost never, because it requires hardware-attested boot state which is fundamentally broken by bootloader unlock. The 10 to 20 percent of apps that require STRONG_INTEGRITY (some neobanks, certain government apps, Google Wallet for tap-to-pay in some regions) cannot be made to work with root by any current method.

What's the best Play Integrity bypass module — Shamiko or TrickyStore?

Shamiko is the easier setup and works for the majority of common banking apps. TrickyStore is more aggressive — it spoofs hardware-attested key responses and can pass certain apps Shamiko cannot, but it has higher detection risk for apps that double-check key store consistency. We recommend starting with Shamiko + Play Integrity Fix and adding TrickyStore only for specific apps that fail with Shamiko alone. Running both at the same time without correct configuration can actually fail more apps than running either one alone.

Why do Play Integrity bypass methods stop working every few months?

Google updates Play Integrity detection logic on a roughly quarterly cycle, and each update usually breaks at least one bypass technique. The community responds within days to weeks with updated fingerprints and module versions. The lifecycle is: Google ships detection update → 90 to 99 percent of bypass setups break → community publishes fix within 1 to 4 weeks → bypass restored. Plan for 1 to 2 weeks per quarter where your banking apps may temporarily refuse to work, and keep an unrooted backup phone or stock-firmware boot.img ready for time-critical transactions.

Will banking apps detect Magisk even with Shamiko enabled?

Some will. Shamiko works by hiding Magisk's process names and Zygisk hooks from Zygisk-checking apps, but apps that use additional detection vectors — checking SELinux state, looking for /system/bin/su, scanning for known root binaries on disk, comparing /proc inconsistencies — can still detect root through those channels. The Play Integrity Fix module addresses the verdict response side; specific app-level detection is a separate problem that varies by app. For 80 percent of apps, Shamiko + PIF is enough. For the remaining 20 percent, app-specific workarounds (or accepting that the app cannot be used on a rooted device) are required.

Is it safe to use my banking app with Magisk DenyList configured?

From a technical security standpoint, yes — DenyList does not weaken the banking app's encryption, certificate pinning, or session security. It only hides the Magisk root state from the app's environment checks. Your banking session is exactly as encrypted and authenticated as it would be on a stock-firmware device. From a contractual standpoint, your bank's terms of service may prohibit running their app on a rooted device — read the terms before relying on it for high-value transactions, and understand that if a fraudulent transaction occurs and your bank discovers root state, they may decline to reimburse. For low-value daily-banking use the trade-off is reasonable; for high-value transactions consider an unrooted secondary device.