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:

EverframeConfig(appId = "evf_app_…", sdkKey = "evf_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.

Report a caught exception

The current source tree also supports handled Kotlin and Java failures:

import dev.everframe.CaptureExceptionOptions
import dev.everframe.ErrorSeverity
import dev.everframe.Everframe

Everframe.captureException(
    error,
    CaptureExceptionOptions(
        severity = ErrorSeverity.WARNING,
        context = "checkout.save-cart",
        metadata = mapOf("attempt" to 2),
    ),
)

The one-argument Everframe.captureException(error) form defaults to error severity. Both forms record handled: true, fatal: false, and mechanism captureException without opening UI or terminating the app. They make a bounded, best-effort encrypted outbox write, request a drain after acceptance, and return before delivery is confirmed. capture.crash = false suppresses both explicit and automatic error capture.

The options overload is source-branch API. Previously published SDK versions may expose an older surface; coordinate the Android SDK version before adopting it.

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"
}

The envelope keeps Raw captured frames. For an optimized build, configure its exact r8MappingId and upload that build’s final mapping.txt through the private R8 workflow. When retracing succeeds, the error detail opens in Retraced mode; Raw remains available.

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 Everframe but visible in Play Console vitals, that is almost certainly why.

R8 retracing applies to Java and Kotlin JVM frames. It does not collect native Android crashes or process NDK/ELF symbols.

Chained handlers

The SDK installs its handler and calls through to whatever was already installed, so adding Everframe does not displace Crashlytics or your own handler. Order matters only in that Everframe 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.