ANR in Android: What It Is, Causes and Solutions

What Is ANR in Android

ANR (Application Not Responding) is a user protection mechanism in Android that triggers when the app stops responding to input. The system tracks event processing time: if BroadcastReceiver does not finish onReceive within 10 seconds, Service does not return from onCreate within 20 seconds, or ContentProvider does not respond within 15 seconds — Android generates an ANR.

What ANR Looks Like to the User

When an ANR occurs, Android shows a system dialog on top of all windows: “App Not Responding. Close it or wait?” The user can close the app or wait for it to recover. If ANRs happen frequently, the user uninstalls the app. Google Play considers the ANR rate — the percentage of sessions with ANR — in its ranking algorithms.

Difference Between ANR and iOS Freezes

iOS has no equivalent of ANR with a system dialog. Instead, Apple uses Watchdog, which terminates the process with exit code 0x8badf00d. The user does not see a dialog — the app simply closes to the home screen. This makes ANR on Android more noticeable to the user but gives the system more diagnostic information.

Main Causes of ANR

ANR occurs when the system tracks a timeout for one of four component types. Each component has its own time limit.

Blocking in BroadcastReceiver

BroadcastReceiver runs on the main thread. If onReceive starts a synchronous network request, a long database write, or waits for a lock — an ANR occurs within 10 seconds. Solution: use goAsync() and WorkManager for background processing. A typical scenario is receiving a Push notification from FCM and synchronously saving to Room.

Long Operation in Service

Service.onCreate and Service.onStartCommand have a 20-second limit. If the service starts heavy initialization (loading libraries, reading config from the network) on the main thread — ANR is inevitable. Use IntentService (deprecated) or WorkManager for guaranteed background execution.

ContentProvider with Slow Initialization

ContentProvider.onCreate runs before Application.onCreate and has a 15-second limit. If the provider performs a database migration, loads dictionaries, or initializes SDK from the network — this causes ANR at app startup. Solution: lazy initialization, offloading heavy operations to WorkManager.

• BroadcastReceiver — 10 seconds for onReceive; use goAsync() for background processing
• Service — 20 seconds for onCreate/onStartCommand; use WorkManager or CoroutineWorker
• ContentProvider — 15 seconds for onCreate; move initialization to Application.onCreate with delayed launch
• UI thread — 5 seconds without processing events; any blocking longer than 5 seconds triggers ANR

How to Diagnose ANR

Android provides several tools for ANR analysis: from system logs to specialized libraries.

Analyzing traces.txt

On each ANR, Android saves the file /data/anr/traces.txt with a stack dump of all app threads. Find the “main” thread — the last method in the stack indicates the cause. Typical patterns: Thread.sleep(), InputStream.read(), BinderProxy.transact(). To extract the file from the device, use adb with superuser privileges.

Firebase Crashlytics with ANR Reports

Firebase Crashlytics automatically collects ANRs and shows them in the dashboard with traces. For Android 11+, ANR reports come with the full main thread stack. Integration requires adding a dependency and initializing FirebaseApp in Application.onCreate.

Android Studio Profiler with Thread Tracing

CPU Profiler in Android Studio lets you record app traces and see which methods consume CPU time. Enable “Record with method traces” and reproduce the scenario that causes the ANR. The timeline will show which methods were running on the main thread at the time of the freeze.

Example of integrating Firebase Crashlytics for ANR collection on Android:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        FirebaseCrashlytics.getInstance()
            .setCrashlyticsCollectionEnabled(true)
        StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build())
    }
}

Methods to Fix ANR

Fixing ANR primarily means moving all long-running operations from the main thread to background threads. Let’s look at specific techniques for each component type.

Using WorkManager for Background Tasks

WorkManager is Google’s recommended solution for background work. It guarantees task execution on a background thread considering the device state. Unlike Service, WorkManager does not block the main thread and is resilient to app restarts. For BroadcastReceiver, use goAsync() and pass the PendingResult to WorkManager.

Kotlin Coroutines with Proper Dispatchers

Run all network requests, database operations, and file I/O with Dispatchers.IO. The main thread should only update the UI. Use viewModelScope for automatic coroutine cancellation when the Activity is destroyed. Avoid runBlocking() in any context — it synchronously blocks the current thread.

Lazy Initialization of ContentProvider

If ContentProvider performs slow initialization, use a lazy loading mechanism: create a provider that returns data immediately and launch heavy initialization through WorkManager with a delay. This prevents ANR at app startup, when the system is most sensitive to delays.

Example of properly using BroadcastReceiver with goAsync in Android:

class FcmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        val pendingResult = goAsync()
        WorkManager.getInstance(context!!)
            .enqueue(OneTimeWorkRequest.from(NotificationWorker::class.java))
        pendingResult.finish()
    }
}

Preventing ANR in Development

The best way to fight ANR is to prevent them during development through tools and architectural decisions.

StrictMode for Detecting Main Thread Blocking

StrictMode with enabled policies detectNetwork() and detectDiskReads()/detectDiskWrites() identifies potential ANRs during development. In Debug builds, set penaltyDeath — any violation will cause an immediate crash, and the developer will see the problem before committing.

Firebase Performance Monitoring for Production Metrics

Firebase Performance tracks the execution time of key operations and shows which scenarios exceed the ANR threshold. Set custom traces for each screen and network request. If execution time exceeds 3 seconds — it’s a potential ANR requiring optimization.

Testing with Network and Disk Latency

Simulate slow conditions: limit network speed using Network Link Conditioner on iOS or Android Emulator. Slow down disk reads by emulating slow memory. ANR often manifest precisely in such conditions; on fast developer devices they are invisible.

• BroadcastReceiver — always use goAsync() for processing longer than 1 second
• Service — replace with WorkManager or CoroutineWorker with a background dispatcher
• ContentProvider — avoid networking and database in onCreate, use lazy-init with WorkManager
• UI thread — StrictMode with penaltyDeath in Debug, Firebase Performance for production monitoring