Crashes and ANRs

A tester says "it closed". Nobody was attached over adb, Logcat is gone, and the crash reporter's dashboard will show it tomorrow at best. This panel keeps the last 50 crashes on the device, with the full stack trace, ready to share as a file.

Uncaught exceptions

AppInspect installs a crash handler that captures uncaught exceptions on every thread, then chains to whatever handler was already there — Crashlytics, Sentry, your own. It does not replace your crash reporter and does not stop it from seeing the crash. Both get it.

The record is written to disk synchronously, before the process dies. That is the only way it can be there on the next launch, and it is why the panel is useful at all.

Each record holds the exception type, the message, the thread name, and the complete stack trace.

ANRs and native crashes

An ANR cannot be caught by a Java handler, and neither can a crash in native code — by definition, nothing in your process is in a position to report it. So AppInspect uses a different mechanism: on Android 11 and newer it reads the OS's own ApplicationExitInfo records on the next launch and turns them into crash entries.

Two consequences follow from that design:

• Reported one launch late. An ANR appears the next time the app starts, not while it is hanging. There is no way around that, and it is still far better than nothing.
• Zero runtime cost. Nothing polls, no watchdog thread runs, no main-thread heartbeat is checked. The OS already recorded it; AppInspect just reads the record.

For an ANR the OS also supplies its thread dump, which is included. That dump is the actual evidence for a main-thread block — it shows what every thread was doing at the moment the system gave up.

On Android 10 and older, uncaught exceptions are still captured; ANR and native crash reporting simply is not available, because the OS API it depends on does not exist.

How much is kept

The 50 most recent records are persisted in AppInspect's app-private SQLite database and survive restarts and reinstalls of the app's process. When the cap is reached the oldest are dropped. Clear inside the panel removes them all.

In release builds none of this happens: the handler is never installed, the exit-info collector never starts, and the bookkeeping file it uses is never written. See the security model.

Getting a crash into a ticket

Copy or share an individual report, or export all of the currently filtered crashes as a .txt through the Android share sheet. A tester can do this themselves, which is the point — the stack trace arrives with the bug report instead of being reconstructed from a description of a white screen.