Root Detection Testing Checklist for Android Apps
A practical checklist for verifying that an Android app's root and tamper detection actually works — and holds up against common bypass techniques.
Root detection is a security control, and like any control it needs to be tested against a real adversary model — not just checked once on a clean emulator. This is the checklist I run for apps that gate functionality on device integrity.
Understand what you are verifying
Root detection usually protects against three things: running on a compromised device, tampering with the app binary, and hooking the runtime to bypass logic. A good test plan covers all three, not just the first.
Baseline: does detection trigger at all?
Start on genuinely rooted environments and confirm the app responds as designed.
- App detects a rooted physical device (Magisk installed)
- App detects a rooted emulator image
- Correct user-facing behavior fires (block, warn, or degrade — per spec)
- Detection event is logged/reported to the backend if required
Resistance: does it survive common bypasses?
This is where most implementations fail. Attackers do not uninstall root — they hide it.
- App still detects root with Magisk Hide / DenyList enabled
- App resists Frida-based hooking of the detection method
- App resists Xposed/LSPosed modules that spoof integrity checks
- Repackaged/re-signed APK is detected (signature check)
- Detection is not defeated by simply toggling airplane mode or clearing data
Coverage: is detection in the right places?
A single check at launch is trivial to bypass. Verify detection is layered.
- Detection runs at launch and before sensitive actions (payment, login)
- Server-side attestation (Play Integrity API) is validated, not just client checks
- Logic is not concentrated in one easily-patched method
False positives: does it leave real users alone?
Over-aggressive detection creates support tickets and one-star reviews.
- Non-rooted devices across OEMs are not falsely flagged
- Custom-but-unrooted ROMs behave correctly where in scope
- Detection does not trip on standard developer options (USB debugging)
Reporting the results
When I write this up, each failed item includes the technique used, the device/tooling, and whether the bypass was trivial or required effort. That distinction matters: a control defeated by Magisk Hide in thirty seconds is a very different finding from one that took a custom Frida script.
The takeaway
Root detection is never “done” — it is an arms race. The goal of testing is not to prove the app is unbreakable, but to raise the cost of a bypass above what your threat model cares about, and to make sure the control degrades gracefully instead of failing open.
