Security model
device_shield runs its checks on the user’s device, inside your app’s
process. That determines what it can and can’t do.
What it’s good for
Section titled “What it’s good for”- Raising the cost of casual tampering. Most rooted phones, emulators and fake-GPS setups are detected without the user doing anything special to hide them.
- Adapting your app’s behaviour. Hide a sensitive screen, ask for extra verification, or disable a feature when the device looks risky.
- Risk signals for your backend. Send the result (the
signals, not justdetected) alongside a transaction and let your fraud rules weigh it. - Keeping screenshots out of sensitive screens on Android, where
FLAG_SECUREis enforced by the operating system.
What it can’t do
Section titled “What it can’t do”- It isn’t attestation. If your server must know that a request comes from a genuine, unmodified copy of your app on a genuine device, use Play Integrity on Android and App Attest on iOS. Both need your server to verify a signed token.
- It isn’t authorisation. Never let a client-side result grant access to anything. The server decides.
- It can’t make iOS block screenshots. Apple provides no supported API for this. See Screenshot protection.
False positives
Section titled “False positives”Heuristic checks fire on legitimate devices too: custom ROMs, developer and engineering builds, and phones with developer tools installed. Blocking these users outright can cost you real customers.
Before you block anyone:
- Log results in production without acting on them.
- Look at which
signalsfire, and on how many real users. - Decide per signal what your app does, and prefer a softer response (extra verification) over a hard block.
Data and privacy
Section titled “Data and privacy”- The SDK makes no network requests and stores nothing.
- Results stay in your app. What you do with them is up to you.
- The iOS privacy manifest declares no tracking, no collected data and no required-reason APIs.