What happens in an ANR
Android expects an app to respond quickly. When the app’s main thread — the one that draws the screen and handles taps — is blocked, for example for about five seconds without responding to input, Android reports an ANR and shows the user a dialog to wait or close the app.
For users it looks like the app froze. Many tap “Close app”, some uninstall, and some write a one-star review about the app “freezing”.
Common causes
- Network requests on the main thread
- Reading or writing files or a database on the main thread
- Heavy calculations or large layouts during startup
- Deadlocks or waiting on a lock held by another thread
- Slow broadcast receivers or services
The ANR rate and Google Play
In the Google Play Console, Android vitals report the user-perceived ANR rate: the share of daily active users who experienced at least one ANR the user noticed. Google’s bad behavior thresholds are:
| Metric | Overall | Per phone model |
|---|---|---|
| User-perceived ANR rate | 0.47% | 8% |
| User-perceived crash rate | 1.09% | 8% |
Above these, Google says your app may be less visible on Google Play and may show a warning on its listing. That makes ANRs a ranking problem, not just a quality problem — see app store ranking.
How to reduce ANRs
- Move I/O and network work off the main thread (coroutines, WorkManager).
- Make startup lighter; defer what isn’t needed for the first screen.
- Use StrictMode in development to catch main-thread disk and network access.
- Check the ANR clusters in Android vitals after every release, and roll out gradually with a staged rollout.
ANRs and crashes go together: see crash rate. Users often report a freeze in a review before it shows up in your dashboards — allstarsbot posts every new Google Play review to Slack or Microsoft Teams so you see those reports the same day.