Application Not Responding (ANR)

The Android SDK uses different implementations to detect ANRs, depending on what version of Android the device is running:

  • Below Android 11: Running a Watchdog thread (v1)
  • Android 11 and above: Reading ApplicationExitInfo (v2)

The new implementation (v2) uses the same data source as Google Play Console. This means the reported ANR events and ANR rate should match with what you see on Sentry. The new implementation also captures a thread dump with additional information, like held locks, to help you resolve ANRs more efficiently.

While the original Watchdog approach (v1) reports many false positives and is based on heuristics, it still has some advantages over v2, like capturing screenshots and transactions with profiles at the time of ANR.

Both ANR detection implementations are controlled by the same flag:

AndroidManifest.xml
Copied
<application>
    <meta-data android:name="io.sentry.anr.enable" android:value="false" />
</application>

Watchdog (v1)

Whenever the main UI thread of the application is blocked for more than five seconds, the SDK will report the problem to the server.

You can also specify how long the thread should be blocked before the ANR is reported. Provide the duration in the attribute io.sentry.anr.timeout-interval-millis in your AndroidManifest.xml:

AndroidManifest.xml
Copied
<application>
    <meta-data android:name="io.sentry.anr.timeout-interval-millis" android:value="2000" />
</application>

ApplicationExitInfo (v2)

This approach reads the ApplicationExitInfo API on the next app launch and asynchronously sends ANR events to Sentry for each ANR in the history, enriching only the latest one with breadcrumbs, contexts, tags, etc.

ANR

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").