Android ANR errors: how to find and fix them
ANR stands for "Application Not Responding". Android shows it when your app's main thread is blocked for too long, typically around five seconds for input events. Users see a freeze and a dialog; Play Console counts it as a quality problem.
Find them
Open Android vitals → ANRs and crashes in the Play Console. Look at the cluster list, the Android versions and the stack traces. Locally, Android Studio's profiler and StrictMode in debug builds point to work on the main thread.
Read the trace
The report shows what the main thread was doing. Look for the first frame from your own code. Typical causes:
- Disk or network on the main thread. Database queries, file reads, synchronous HTTP.
- Lock contention. The main thread waits for a lock a background thread holds.
- Heavy work in
onCreate, a broadcast receiver or a service start. These run on the main thread unless you move the work. - Slow startup, for example initializing many SDKs at once.
Fix
- Move blocking work to a background dispatcher or
WorkManager, and update the UI when it returns. - Defer SDK initialization until after first draw when you can.
- Keep broadcast receivers short and hand off the work.
- Add StrictMode in debug builds so new violations fail loudly during development.
Test it
ANRs often show up only on slow devices and with large data. Test on an old low-end phone, with a big database, and with the network throttled. Ask testers on cheap devices to run the main flows; our device guide explains how to pick them.
Questions developers ask
Is an ANR the same as a crash? No. The app does not close by itself, the user sees a freeze and may force-quit.
Which ANRs matter most? Those at startup and in your main flow, and any that Play Console flags as above the bad-behavior threshold.
Need testers for your app? Open a test group on AppReviewX. Start free