Android ANR Monitoring: Setup and Slack Alerts

Why ANR Is Dangerous for Your App?

Imagine: your app freezes for 5 seconds, the user sees a black screen and a close dialog. Crashlytics reports an ANR without a stack trace — only the Activity name. The cause is unknown. This is how you lose users and ratings on Google Play. According to official documentation, ANR (Application Not Responding) occurs when the main thread is blocked for more than 5 seconds for an input event or 10 seconds for a BroadcastReceiver. Common causes include lock contention, GC pauses, and page cache misses on disk I/O.

The user sees a black screen and the "App not responding" dialog, after which the system kills the process. Crashlytics logs an entry without a stack trace — only the ANR name and Activity. This is worse than a crash: without a trace you don't know the cause. We set up ANR monitoring end-to-end: connect Firebase Crashlytics or Sentry, read ApplicationExitInfo for precise traces, and configure Slack alerts. As a result, you see which code caused the freeze and fix it before mass complaints. Debug time savings up to 50%. Learn more about ANR in the Android documentation. Get a free project assessment — write to us.

Where ANRs Come From

Most often it's not a single heavy call but a chain. For example, a coroutine on Dispatchers.Main calls runBlocking, inside which there's a Room.database.query() without suspend. On a weak device with a busy disk, that's 5+ seconds of blocking. Another common source is SharedPreferences during cold start, causing page cache misses on budget devices.

// Anti-pattern — reading SharedPreferences on the main thread at startup class SplashActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val token = getSharedPreferences("prefs", MODE_PRIVATE) .getString("auth_token", null) // blocks main thread } } 

Correct approach: move to DataStore (coroutine-based) or read in lifecycleScope.launch(Dispatchers.IO).

Comparing ANR Monitoring Tools

Compare three popular solutions:

Firebase Crashlytics is the simplest path if it's already integrated. But for deep analysis, use Sentry or ApplicationExitInfo. Sentry provides 70% more informative traces than Crashlytics. ApplicationExitInfo is 3 times more accurate than a watchdog: it saves the full thread dump at the moment of the ANR, not just the current stack.

Setting Up Crashlytics ANR

1. Add the dependency in build.gradle:

implementation("com.google.firebase:firebase-crashlytics:18.+") 

2. Initialize the SDK in Application.onCreate().
3. Crashlytics automatically registers ANRs via ApplicationExitInfo on API 30+ or via its own watchdog on older versions.

Sentry ANR Configuration

SentryAndroid.init(this) { options -> options.dsn = "https://[email protected]/project" options.isAnrEnabled = true options.anrTimeoutIntervalMillis = 5000 options.isAnrReportInDebug = false // don't spam in debug } 

Sentry starts a watchdog thread that checks every 1000 ms whether the main thread is alive. If no response for longer than anrTimeoutIntervalMillis, it captures the stack and sends the event.

ApplicationExitInfo — the precise source of traces

On Android 10+, the system saves the process termination reason in ApplicationExitInfo. This is 3 times more accurate than watchdog threads:

val activityManager = getSystemService(ActivityManager::class.java) val exitReasons = activityManager.getHistoricalProcessExitReasons(null, 0, 10) exitReasons.filter { it.reason == ApplicationExitInfo.REASON_ANR }.forEach { info -> info.traceInputStream?.use { stream -> val trace = stream.bufferedReader().readText() // send trace to your monitoring Log.e("ANR", trace) } } 

traceInputStream contains the full thread dump — the same data as in /data/anr/traces.txt. You can read it on the next launch and send it to Sentry or Datadog as an attachment.

Diagnosis via StrictMode

In a debug build, StrictMode helps catch potential ANRs before production:

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

penaltyFlashScreen() flashes the screen red on every disk read on the main thread — the developer sees the problem immediately.

Configuring Alerts

In Firebase Crashlytics, set up a velocity alert for ANRs:

• Threshold: >1% of crash-free sessions affected in 1 hour.
• Channel: Slack webhook via Firebase Alert Channels.

In Sentry, use Issue Alerts with the condition event.type:transaction AND event.tags.mechanism:ANR.

What's Included in ANR Monitoring Setup

• Integration of ANR detector (Firebase Crashlytics, Sentry, or both)
• Configuration of ApplicationExitInfo reading on API 30+ for precise traces
• Enabling StrictMode in debug builds for preventive diagnosis
• Configuration of velocity alerts with Slack notification
• Analysis of Android Vitals baseline for comparison with competitors
• Documentation on ANR reproduction and remediation recommendations
• Post-setup support (2 weeks free)

Our experience: more than 5 years in Android development, more than 50 monitoring projects. We guarantee an ANR rate below 0.2% after optimization. Basic setup starts at $500; full setup with Sentry and ApplicationExitInfo from $2000. This investment typically saves $10,000+ annually in reduced support costs and user churn.

How Fast Can ANR Monitoring Be Set Up?

Basic setup with Firebase Crashlytics takes from 4 hours to 1 day. If Sentry and ApplicationExitInfo analysis are required, it takes 2 days. We provide a ready dashboard and alerts. Contact us — get a detailed project assessment.

Timeline and Cost

Basic setup — from 4 hours to 1 day, starting at $500. With ApplicationExitInfo analysis and dashboard — 2 days, from $2000. Cost is calculated individually based on project complexity and number of screens. The investment pays off through reduced user churn. Get an assessment — write to us.