Android Bug Report: What It Captures and What It Misses

An Android bug report is a diagnostic dump of device and system state — captured from the device or through developer tooling, and useful for exactly the kind of problem where system state is the evidence. It is not the same thing as the report a tester writes, and confusing the two wastes time in both directions.

This page is about the Android meaning: what a device dump gives you, what a crash reporter adds on top, and the gap that neither closes.

Three sources of Android bug data

They answer different questions and most teams need more than one.

The Android bug report location and the exact capture route depend on which tool you used, so check the current developer documentation rather than a blog post. A device dump is the right instrument when you have the device and the problem is reproducible in front of you. It is the wrong instrument for production, because the failures that matter happen on other people’s phones.

What a crash reporter covers

Firebase Crashlytics is the default on Android and the reference point worth knowing in detail, because its limits shape what your crash history actually contains.

Once the SDK is added and initialised, crash reports are collected automatically for all users with no further instrumentation in app code. Crashlytics analyses crash, non-fatal and ANR events and groups them into issues based on stack trace frames, exception messages, error codes and other platform signals, with each issue viewable in the Firebase console as an event report carrying stack traces, logs and keys. There is no cost to using it.

For ANR monitoring specifically, and for native crashes, two recent changes matter. From Crashlytics NDK SDK version 18.3.6, announced on 14 November 2025, Crashlytics began collecting Android tombstone crash reports on devices running Android 12 — API level 31 — and higher, combining minidump and tombstone data so it can display side-by-side symbolicated stack traces. Tombstone reports now run through the same symbolication pipeline as minidumps, so app frames get symbols, file names and line numbers. And in January 2026 Firebase added an integration exporting Crashlytics data — fatal crashes, non-fatals and ANRs — directly into Google Cloud Logging, configured from the Firebase console under Project Settings and Integrations.

The ceilings

Worth knowing before you treat crash history as a complete record:

1. 64 custom key-value pairs maximum, each up to 1 KB. Once the threshold is reached, additional pairs are not saved.
2. Session logs capped at 64 KB. When exceeded, older entries are removed starting from the oldest to keep the log within the cap.
3. Eight exceptions per session. Only the most recent eight recorded exceptions are kept; earlier ones are lost.
4. About 90 days of retention. Stack traces, extracted minidump data, Crashlytics Installation UUIDs and Firebase installation IDs are kept roughly 90 days before removal begins, and the dashboard retains crash data for the same window.
5. NDK minidumps are transient. For native crashes, Breakpad-formatted minidump data is stored only while the crash session is being processed, then discarded.

Crashlytics is widely deployed — Appfigures ranks it at 40% market share among performance SDKs in App Store apps — so these ceilings are the de facto shape of crash history for a large part of the ecosystem.

The gap neither one closes

Here is the thing a device dump and a crash reporter have in common: both record what the system did, and neither records what the person was doing.

That distinction is not academic. A large share of the bugs that damage a product do not crash anything. The checkout completes and charges the wrong amount. The video plays without sound. The back button loses a half-filled form. No exception is thrown, no ANR fires, nothing appears in a crash dashboard — and the only signal that anything went wrong is a person deciding to tell you.

For the crashes that do fire, intent still explains more than the stack trace does. Knowing an exception occurred in a payment view is useful. Knowing the user had been retrying a declined card for four minutes before it happened is what identifies the bug.

Filling it in

A user-filed report is the third source, and the difficulty has always been that asking a person to reconstruct build, device and steps from memory produces reports nobody can act on.

TraceItX captures those automatically. The reporter lives inside your Android app — the SDK is a 92 KB archive requiring API level 24 or later, added as a single dependency — and a person presses a bubble or shortcut, annotates the screenshot, blurs anything sensitive, and sends. What arrives is one AI-ready envelope with the annotated screenshot, Logcat output and network calls, device and app context, the build, and the trail of screens and actions leading to the report. Activity transitions are recorded automatically; Compose and single-Activity navigation need one line. Crash reporting is on by default and produces the same envelope shape, so an unattended failure arrives with the breadcrumb trail a person would have supplied.

The same SDK covers Android phones, tablets, Android TV and Fire TV, and the TV reporter is built for a D-pad rather than a touchscreen — which matters if your Android surface includes a living-room app, where getting a tester to file anything at all is the harder problem.

Which to reach for

1. You have the device and can reproduce it — take the device dump. Nothing else gives you that depth of system state.
2. The app is failing in production — you need a crash reporter, and Crashlytics costs nothing to add.
3. Something is wrong but nothing crashed — you need a person to tell you, and the report needs to carry context they did not have to type.

Most Android teams have the first two and treat the third as a process problem. It is usually a capture problem, and the way to find out is to count how many of last quarter’s bugs were closed because nobody could reproduce them.