Available on Starter and above
ANR detection is included from the Starter plan. On Free, the SDK doesn't report ANRs; upgrading turns it on from the next app launch, with no new release. See Plans & features.Setup
None. ANR monitoring starts with the SDK. How it works depends on the Android version on the device.
Android 11 and higher (API 30+)
Android keeps its own record of why each app process ended, including ANRs. On the next launch, the SDK reads the records it hasn't seen yet and reports each ANR once, along with Android's description of it.
- Accurate: these are the ANRs Android itself recorded, the same ones users see.
- No runtime cost: nothing runs while your app is in use. The records are read once, in the background, at startup.
- Reported on next launch: an ANR shows up after the user opens the app again.
Android 7 to 10 (API 24–29)
These versions don't expose exit records, so the SDK runs a small, low-priority watchdog thread instead. Every few seconds it checks whether the main thread is responding. If the main thread stays blocked for about five seconds, the SDK records an ANR.
Watchdog reports are a close approximation
The watchdog sees that the main thread was blocked, not whether Android actually showed the “app isn't responding” dialog. Treat these reports as main-thread freezes worth investigating.What's attached
Every ANR carries the same device, app version and user context as a crash (see Crash reporting). ANRs from Android's exit records also include Android's own description.
In version 0.3.0, ANR reports don't yet include a main-thread stack trace. To find the cause, group ANRs by app version, device and screen, and look for main-thread work such as disk, database or network calls that should run on a background dispatcher.
Reliability guarantees
- ANRs are never sampled away and are never dropped to free queue space.
- ANR capture can be turned off for a project in the dashboard under Settings → SDK settings (remote config). It's on unless it's switched off there.