Crash reporting

Crash reporting is on by default — the payload is data the SDK already holds (the exception plus the breadcrumb trail), fully redacted. It is a client veto:

TraceItXConfig(appId = "txx_app_…", sdkKey = "txx_live_…", capture = CaptureConfig(crash = false))

Delivery is on the next launch

A process that has died cannot upload anything. The report is written to the outbox and sent when your app next starts, which has one consequence worth building your triage around:

occurredAt and submittedAt are different times, sometimes by days. Order on occurredAt. A crash loop otherwise looks like it all happened at once, at the moment the user finally reopened the app.

requestOutboxDrain() asks the outbox to flush immediately rather than waiting for its own schedule — useful right after startup if you want crash reports promptly.

What arrives

{
  "exceptionType": "java.lang.NullPointerException",
  "message": "Attempt to invoke virtual method 'int java.util.List.size()' on a null object reference",
  "frames": [
    {
      "raw": "at com.example.CheckoutViewModel.total(CheckoutViewModel.kt:42)",
      "file": "CheckoutViewModel.kt",
      "function": "total",
      "line": 42
    }
  ],
  "mechanism": "uncaught-exception-handler",
  "handled": false,
  "occurredAt": "2026-06-15T11:59:58.400Z",
  "fingerprint": "9f2c1ab30d84e177"
}

Frames are raw — deobfuscation is not in v1, so a release build with R8 gives you obfuscated class and method names. Keep the mapping file for every build you ship; mapping happens on your side for now.

mechanism is a plain string, not an enum, so v2 can add values without older receivers rejecting reports.

What is not caught

Thread.UncaughtExceptionHandler sees JVM exceptions. It does not see:

• Native crashes — a SIGSEGV in NDK code or a bundled .so
• ANRs, which are not exceptions at all
• Low-memory kills by the system

Those are not in v1. If a crash is missing from TraceItX but visible in Play Console vitals, that is almost certainly why.

Chained handlers

The SDK installs its handler and calls through to whatever was already installed, so adding TraceItX does not displace Crashlytics or your own handler. Order matters only in that TraceItX records first, which is what lets it capture the breadcrumb trail before another handler terminates the process.

Grouping

fingerprint is 16 hex characters computed on the client from the exception type and the top frames — a heuristic, deliberately, so grouping works with no server round-trip and no deobfuscation step. Treat it as a strong hint, not an identity.

What comes with it

An unattended report has no description — nobody typed one. Its title is the exception type and message. What makes it useful is the breadcrumb trail leading to the throw — console, network, taps and the screen the user was on — plus device metadata and the user, if one was set.

It carries no screenshot and no replay: the handler runs synchronously in a dying process, and only what is already in memory as breadcrumbs is written out.