To evaluate Android root detection, separate three kinds of evidence, test each on the devices your customers really use, and decide in advance what the app does at each level of confidence. Root traces show that root tooling is present. Boot and system state shows that the device is no longer locked and stock. Platform device trust, verified on your server, shows what Google and the hardware attest. No single group settles every case, so ask any solution to report them separately. This guide covers Android apps only; jailbroken iOS devices need their own evaluation with their own evidence.
The Otukan control is covered on Android root detection.
Signal boundary
Before comparing solutions, agree what each signal can and cannot prove. Mixing them into one yes-or-no answer hides the reason a device was flagged.
| Evidence group | What it shows | Where it is checked | How an attacker hides it | What it cannot tell you |
|---|---|---|---|---|
| Root traces | Root tools, managers or changed system files are present | Inside the app | Remove or rename files, hide from chosen apps | Whether the boot chain is intact |
| Modified boot and system state | Bootloader unlocked, custom image or verified boot not green | Inside the app, and in key attestation on your server | Spoof properties in the app’s view | Whether root is active right now |
| Platform device trust | Play Integrity labels such as basic, device and strong integrity | On your server, from a Google-signed verdict | Harder: the verdict is signed outside the device | Which specific trace was found |
Questions for each solution
- Does the result name which evidence group fired, or only return “rooted”?
- How does the solution behave when root is hidden from the app specifically?
- How does it treat an unlocked bootloader with no root tools installed?
- Can your server combine the in-app result with a Play Integrity verdict it verifies itself?
- What happens on devices sold without Google Play services?
How Otukan answers. Otukan reports root traces, boot and system state, and hiding behaviour as separate groups, and its in-app checks keep working where Play services are absent. Your server can add a Play Integrity verdict and a hardware key attestation result it verifies itself, so the final call rests on evidence from inside and outside the app.
Compatibility
Root detection fails in two ways: it misses a rooted device or it flags a legitimate one. Only testing on real Android hardware shows which.
Build your device matrix
- List the manufacturers and models that carry most of your sessions, from your own analytics.
- Add older and lower-cost models, which often run manufacturer builds with unusual properties.
- Add one device per supported Android release, at least for the oldest and newest you support.
- Add devices without Google Play services if you serve markets where they are common.
Include legitimate unusual devices
- A developer phone with developer options and USB debugging enabled but no root.
- A phone with an unlocked bootloader and a stock image.
- A phone running a custom system image chosen for privacy or longer updates.
- The emulators your own test automation uses, run through your CI/CD pipeline.
Developer options and USB debugging are not root. A solution that treats them as root will flag your own engineers and many power users.
Record every run
For each device, write down the Android version, the patch level, the evidence group reported and the expected result. Repeat the run after a major Android release and after your own app update.
How Otukan answers. Otukan tests root checks with your team on physical devices across manufacturers before your protected release ships, including your developer and unusual devices, and records the results per device.
Decision
A root signal becomes useful when it maps to proportionate app behaviour. Decide the mapping before launch, flow by flow.
| Evidence observed | Confidence | Suggested starting behaviour |
|---|---|---|
| Unlocked bootloader, no root traces | Low | Record; no change for the customer |
| Root traces present | Medium | Step up before payments; shorten the session |
| Hiding behaviour detected | Medium to high | Treat as root on sensitive flows |
| Server verdict fails device integrity plus in-app traces | High | Refuse high-value actions; offer a supported path |
Settle these before go-live
- Which flows keep working on a rooted device: browsing, balance view, support chat?
- What message does the customer see, and does it offer a way forward?
- Who reviews the rate of each evidence group in the first weeks, and who can relax a rule?
- How does your backend log the evidence group with the account, for fraud and support teams?
How Otukan answers. Otukan maps each evidence group to the response you set per flow: observe, warn, restrict or terminate. The evidence also travels to your backend with the request it concerns, so the server can combine it with account context before it acts.
Broader Android guidance is covered on Android app security, and the edge cases are covered on root detection limitations. The iOS counterpart is the iOS jailbreak detection solution guide.