The Failure That Never Shows Up in Your Crash List — Collecting ANR Traces with ApplicationExitInfo and Handing Triage to an Agent

ANRs never reach your crash handler. Here is how I collect them at startup with ApplicationExitInfo and hand triage to an Antigravity agent, with five weeks of real numbers.

Antigravity³⁷⁷ Android²⁷ANRApplicationExitInfoPlay Console

✦ Premium Article

Late last year I opened the Play Console for a wallpaper app I run as an indie developer. The crash rate was under 0.1%, and the crash list had been quiet for weeks. Yet the user-perceived ANR rate had climbed to 0.62% — past the 0.47% bad-behavior threshold.

Not a single new crash, but the quality metric kept sinking. It took me longer than I would like to admit to understand that asymmetry. ANRs happen through a different mechanism than crashes, and they can only be observed through a different one, too.

This article walks through collecting those ANRs yourself with ApplicationExitInfo, the constraints I use when handing trace triage to an Antigravity agent, and what five weeks of running the pipeline actually changed.

Why ANRs never reach your crash handler

Most homegrown crash reporting is built on Thread.setDefaultUncaughtExceptionHandler. If a JVM exception is thrown, you catch it.

An ANR never passes through that path. When the main thread stops responding, no exception is thrown inside your process. The system decides from the outside that the process is unresponsive, shows the dialog, and usually kills the process. There is simply no moment at which your handler gets called.

Event	UncaughtExceptionHandler	ApplicationExitInfo (API 30+)
JVM crash	Caught	Recorded as REASON_CRASH
Native crash	Not caught	Recorded as REASON_CRASH_NATIVE
ANR	Not caught	Recorded as REASON_ANR, with a trace
OOM kill / force stop	Not caught	REASON_LOW_MEMORY / REASON_USER_REQUESTED

To be fair: Firebase Crashlytics also reports ANRs on API 30 and above, and it uses the same ApplicationExitInfo underneath. If all you want is a rate on a dashboard, that is enough.

I went down the self-collection path for one reason: I wanted the full trace text inside my own pipeline. Not a collapsed stack in an aggregation UI, but the raw trace, as plain text, ready to be fed to an agent. Everything in the second half of this article starts from that.

Collecting last session's ANRs at startup

ApplicationExitInfo is a query-after-the-fact API. You cannot do anything at the moment the ANR happens, but on the next launch you can retrieve the reason and the trace.

What this code solves: at app startup, it queries the previous process's exit history and persists only the ANRs locally.

class ExitInfoCollector(private val context: Context) {
 
    private val prefs =
        context.getSharedPreferences("exit_info_collector", Context.MODE_PRIVATE)
 
    // Call from Application.onCreate on Dispatchers.IO.
    // Reading the trace on the main thread can itself seed the next ANR.
    fun collect() {
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.R) return
 
        val am = context.getSystemService(ActivityManager::class.java)
        val lastSeen = prefs.getLong("last_timestamp", 0L)
 
        val reports = am.getHistoricalProcessExitReasons(context.packageName, 0, 16)
 
        reports
            .filter { it.timestamp > lastSeen }
            .filter { it.reason == ApplicationExitInfo.REASON_ANR }
            .forEach { info ->
                val trace = runCatching {
                    info.traceInputStream?.bufferedReader()?.use { r -> r.readText() }
                }.getOrNull()
 
                saveReport(
                    timestamp = info.timestamp,
                    description = info.description ?: "no description",
                    trace = trace
                )
            }
 
        // Remember the newest timestamp across all reasons to avoid reprocessing
        reports.maxByOrNull { it.timestamp }?.let {
            prefs.edit().putLong("last_timestamp", it.timestamp).apply()
        }
    }
 
    private fun saveReport(timestamp: Long, description: String, trace: String?) {
        val dir = File(context.filesDir, "anr_reports").apply { mkdirs() }
        val body = buildString {
            appendLine("timestamp: $timestamp")
            appendLine("description: $description")
            appendLine("---")
            append(trace ?: "trace unavailable")
        }
        File(dir, "anr_$timestamp.txt").writeText(body)
    }
}

Why it is written this way — three things matter.

The trace can be null. traceInputStream only returns a value for REASON_ANR and REASON_CRASH_NATIVE, and even for ANRs it is sometimes missing depending on device and timing. In my app the retrieval success rate hovered around 84%. Always persist the description even when the trace is gone, so at least the fact of the ANR survives.

Deduplicate by timestamp. getHistoricalProcessExitReasons returns history as-is; without bookkeeping you would process the same reports on every launch. Storing the newest processed timestamp is unglamorous and sufficient.

Keep the collector itself off the main thread. Traces can run to hundreds of kilobytes. Reading one synchronously inside Application.onCreate means the code you wrote to observe ANRs starts manufacturing them.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A startup-time ApplicationExitInfo collector for ANR traces, with timestamp deduplication and a fallback for missing traces

✦Three ANR patterns that AI-generated code tends to introduce, with Before/After fixes that move work off the main thread

✦Constraint design for handing traces to an agent (verbatim quoting, max three candidates, human-reviewed fixes) and five weeks of measured results

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Three ANR patterns that AI-generated code tends to introduce

Within the first two weeks of collecting, the ANRs in my app converged on three patterns. All three came from screens I had delegated to an agent — code that works, compiles, and runs fine on a fast development device, which is precisely why it slips through review.

Pattern	How it looks in the trace	Typical screen
Full-size bitmap decode on main	main inside BitmapFactory.decodeFile / decodeStream	Applying a wallpaper, generating share images
Synchronous work inside a BroadcastReceiver	main blocked on I/O inside onReceive	Date-change or connectivity receivers
Repeated SharedPreferences commit()	main waiting in QueuedWork.waitToFinish	Settings screens, bulk favorite operations

Here is the first pattern as a Before/After.

This is the version that does not hold up. For 4K-class wallpaper images, this single decode line takes seconds on slower devices.

// Before: decoding the full-size bitmap on the main thread right before applying
fun applyWallpaper(file: File) {
    val bitmap = BitmapFactory.decodeFile(file.absolutePath)
    WallpaperManager.getInstance(context).setBitmap(bitmap)
}

The fix moves both decode and apply to the IO dispatcher and downsamples to the display size.

// After: decode and apply on IO; drop excess resolution with inSampleSize
suspend fun applyWallpaper(file: File, targetWidth: Int) =
    withContext(Dispatchers.IO) {
        val opts = BitmapFactory.Options().apply { inJustDecodeBounds = true }
        BitmapFactory.decodeFile(file.absolutePath, opts)
 
        val sample = generateSequence(1) { it * 2 }
            .first { opts.outWidth / (it * 2) < targetWidth }
 
        val bitmap = BitmapFactory.decodeFile(
            file.absolutePath,
            BitmapFactory.Options().apply { inSampleSize = sample }
        )
        WallpaperManager.getInstance(context).setBitmap(bitmap)
    }

The second pattern has hard deadlines: a foreground receiver has roughly ten seconds, and input dispatch has five, before the system declares an ANR. When you find generated code doing synchronous I/O inside onReceive, the standard moves are goAsync() for a short grace period or delegating to WorkManager.

The third pattern exists because commit() is a synchronous write with an fsync. Swapping in apply() buys you time, but lifecycle boundaries still wait on QueuedWork, so for write-heavy screens the more honest fix is migrating to DataStore.

Constraints for handing trace triage to an agent

This is where Antigravity earns its keep. ANR traces are long, with dozens of threads besides main. Triaging them by eye is not work I would wish on anyone at the end of a day.

That said, I do not paste the whole trace and ask the agent to "find and fix the cause." On another project I once received a fix justified by a stack frame that did not exist in the trace. Since then I keep three constraints:

Input: unprocessed traces under anr_reports/
 
Constraints:
1. Every frame cited as evidence must be quoted verbatim from the trace.
   No conclusions based on frames that cannot be quoted.
2. At most three candidate causes. Each must name the thread involved,
   the lock being held, and the matching source file in the app.
3. No code changes. Output a triage report only.
   Fixes are reviewed and applied by a human.

Before handing anything over, I pre-trim the trace to the main thread's stack plus whichever threads hold the locks main is waiting on. That cuts the input to about a tenth of its size, and the triage quality became noticeably steadier. Narrowing where the agent should look works better than asking it to consider everything.

I also want to be explicit about why the agent does not get to write the fix. ANR fixes usually change threading boundaries, and the blast radius is wider than the stack makes it look. Machines do the sorting, humans make the call — that division is the one I can sleep with.

What five weeks of running this changed

These are numbers from a single app, so please do not over-generalize. But they are honest.

Metric	Before	After 5 weeks
User-perceived ANR rate	0.62%	0.21%
ANR reports collected	—	47 (trace retrieval 84%)
Root causes identified and fixed	—	3 (one of each pattern above)
Triage time per report	~40 min (by eye)	~10 min (report review + verification)

Once the rate dropped back under the 0.47% threshold, the slide in search-driven impressions stopped as well. I will not claim causation, but Google does state officially that Play Console quality metrics affect discoverability. For reading those metrics, see how I put Play Console statistics to work in analysis; for a similar measure-first approach to startup, see tuning Android cold start with Baseline Profiles, measured.

As a next step, wire in the ExitInfoCollector and simply read one week of reports. Your crash list may be quiet — but there may be a different picture developing just outside its frame. If you are staring at the same stubborn metric, I hope this saves you some of the detour it cost me.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.