An Android app should respond to evidence of root access with a proportionate, per-flow decision, not a blanket block. Otukan gathers that evidence from inside the app in several groups: root artefacts, systemless root and hiding tools, and boot and system state. Your server can add a Play Integrity verdict and key attestation result it verifies itself. Otukan then applies the response you chose for each flow: observe on browsing, step up at login, restrict payments. Rooted sessions lose access to what matters, and legitimate users on unusual devices keep working. This page covers Android; iOS jailbreak detection is its own control.
The broader set of runtime checks is covered on mobile RASP.
Signal categories
Root signals differ in how they are gathered and how easily they can be faked. Otukan keeps them in separate groups, so your policy knows exactly what each one shows.
Root artefacts
Rooting usually leaves something behind: an su binary on the path, a root manager app, writable system directories, or build properties such as test signing keys. Otukan checks for these quickly, from inside the app. They are the first layer, and the layers below catch what a careful attacker removes.
Modified environments
Systemless root leaves the system partition unchanged and applies its changes at boot. Hiding features conceal root from chosen apps. Otukan looks past the missing files at mount state, SELinux mode, code loaded into the app’s own process and the side effects of hiding. This group overlaps with hooking detection, because root is how most hooking tools get in.
Platform trust signals
Android also offers evidence from outside the app. A Play Integrity verdict is signed and encrypted by Google, and your server decodes and checks it. Hardware-backed key attestation through Android Keystore returns a certificate chain that includes the verified boot state and whether the bootloader is locked. Otukan’s in-app signals complement both.
| Signal group | Where it is evaluated | Resistance to hiding | What it adds |
|---|---|---|---|
| Root artefacts | In the app | Lower | Fast, broad first layer |
| Modified environments | In the app | Medium | Catches systemless root and hiding |
| Play Integrity verdict | On your server | Higher | Google-signed device labels |
| Key attestation | On your server | Higher | Hardware-backed boot and lock state |
Risk decision
Every signal is an input. Otukan’s value is in combining them and handing your policy a clear picture.
Working with false positives and false negatives
Legitimate users can look rooted: people running custom system images for privacy or longer updates, developers with unlocked bootloaders, manufacturer builds with unusual properties, and devices sold without Google Play services. Attackers try the opposite, hiding root or patching checks out of the app. Otukan handles both sides with layered evidence and server-side decisions. Because Otukan reports which group fired, an unlocked bootloader can get a lighter response than an active root manager.
Proportionate responses
| Flow | Recommended starting response | Why |
|---|---|---|
| Browsing and public content | Observe and record | Root changes little about the risk here |
| Login | Send the signal with the request; step up on the server | The backend combines it with account and session context |
| Stored credentials or tokens | Restrict local storage of sensitive data | Root access can read app storage |
| Payments and account changes | Step up or refuse, based on combined signals | The cost of a wrong decision is highest |
Start in observe mode, measure how often each check fires on your real users, then tighten flow by flow. Policy design for runtime signals is covered on threat response.
Compatibility
OS versions
Android keeps changing what an app can see. For apps targeting Android 11 (API level 30) or later, package visibility rules limit which installed apps an app can query, which affects checks that look for root manager apps. Google has deprecated the SafetyNet Attestation API in favour of Play Integrity. Otukan’s checks are designed around these rules rather than against them, and each check carries its own tested Android version range.
App layers and distribution
Where a check runs matters. Checks written only in Java or Kotlin are easy to find in a decompiled app, so Otukan places its checks where they are harder to locate and patch. Native Android, Flutter and React Native apps get the same protection, and the result reaches your policy directly rather than through app code an attacker can edit. With Play App Signing, the certificate on the device is Google’s app signing key, not your upload key, and Otukan’s integrity checks expect the right one.
Device diversity
Manufacturers customise system images, file layouts and security settings. Otukan tests root checks on physical devices across manufacturers and price tiers, including older and lower-cost models, not only current flagship phones.
Release regression
Otukan maintains root checks as Android releases and hiding tools change. Before your protected release ships, we prove each check with your team:
- Reproduce root in an authorised lab and confirm the expected signal.
- Run the same journey on a legitimate, supported device and confirm the check stays quiet.
- Repeat install, update, login and your most sensitive flow on the protected build.
Results are recorded with devices, Android versions and the reviewer. Android-specific guidance is covered on Android app security, and the edge cases are covered on root detection limitations.