ANR Errors Explained and How to Fix Them

An ANR happens when your app's main thread can't respond in time: to an input event, a broadcast, or a service start. The user sees a dialog offering to close the app. Unlike crashes, ANRs often hide in rare conditions: slow storage, lock contention, or a slow network call made synchronously.

ANR types and timeouts

Exact values vary by Android version. The principle is constant: never block the main thread.

Common culprits

• Disk I/O on main: synchronous SharedPreferences commit(), large file reads, database queries.
• Network on main, often hidden inside a "quick" SDK call.
• Lock contention: the main thread waits for a lock held by a busy background thread.
• runBlocking on the main thread to call suspend code.
• Heavy work in onReceive or in Application/Activity creation.
• Binder calls to slow system services or other apps' content providers on main.

Diagnosing from ANR traces

1. Open Android vitals → ANRs in the Play Console, or Crashlytics if you use it, to see clusters by stack trace.
2. Look at the main thread stack ("main" thread) in the trace. Its top frames show what it was doing or waiting on.
3. If main is WAITING or BLOCKED on a lock, find the thread that holds the lock in the same trace.
4. Reproduce locally with a slow device or emulator, network throttling, and StrictMode enabled.

"main" prio=5 tid=1 Native
  at android.database.sqlite.SQLiteConnection.nativeExecuteForCursorWindow(Native Method)
  at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java)
  ...
  at com.example.orders.OrdersRepository.getAllBlocking(OrdersRepository.kt:42)
  at com.example.orders.OrdersActivity.onCreate(OrdersActivity.kt:31)

Here the fix is obvious: getAllBlocking runs a database query from onCreate on the main thread.

Fixes

// ❌ Blocking in onCreate
val orders = repository.getAllBlocking()

// ✅ Suspend + lifecycle-aware collection; Room handles threading
lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        repository.observeOrders().collect(adapter::submitList)
    }
}

class SyncTriggerReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Don't sync here; schedule it.
        WorkManager.getInstance(context).enqueueUniqueWork(
            "sync", ExistingWorkPolicy.KEEP, OneTimeWorkRequestBuilder<SyncWorker>().build(),
        )
    }
}

• Use apply() rather than commit() for SharedPreferences, or better, migrate to DataStore.
• Replace runBlocking with coroutines launched in a proper scope.
• Avoid holding locks during I/O. Prefer coroutine Mutex on background dispatchers.
• Initialise SDKs lazily and off the main thread where supported.

Prevent with StrictMode

if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(
        StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().penaltyFlashScreen().build()
    )
}

Real cases

Frequently asked questions

Conclusion

ANRs come from a blocked main thread. Find the cause in the main thread's stack in ANR traces, move I/O and heavy work to background dispatchers or WorkManager, avoid runBlocking and lock contention, and catch regressions early with StrictMode.

Next step: make the first impression fast with Reducing Android App Startup Time.