Android

The planned Android library will capture errors and crashes from native Kotlin and Java apps and report them to TracePath alongside everything else in your organization.

What it will capture

Initialization from Application.onCreate() wraps the whole process, so these need no per-call wiring:

• Uncaught Java and Kotlin exceptions on every thread, through the default uncaught exception handler
• View click handler throws, including exceptions inside dialog button handlers and similar UI callbacks
• Background thread throws, anything that escapes a thread's run() body
• Main-looper Handler.post throws
• Activity lifecycle transitions, recorded as navigation actions

Explicit capture calls will cover caught exceptions, custom messages and a forced flush.

Network and internet permissions come from the library's own manifest, folded into your app by the Android manifest merger, so there is nothing to declare yourself.

No screen recording. Unlike the planned Flutter SDK, the Android library does not record video. Options that exist in the Flutter SDK for screen capture are accepted only for API parity and have no effect on Android.

Logs and actions

Each captured exception will ship with the last ~10 seconds of session context: two independent rolling buffers, logs and actions, each capped at 200 entries by default.

Logs mirror writes to the standard output and error streams. Calls that go straight to android.util.Log bypass those streams and are not captured automatically — picking them up will mean installing a logging tree (Timber or equivalent) that forwards each line to the SDK. Plan for that if Logcat is where your app's diagnostics actually live.

Actions come from three sources:

• Network — HTTP requests routed through an OkHttp client with the SDK's interceptor installed, which covers Retrofit, Coil and Glide-over-OkHttp as well as your own calls. Clients that are not OkHttp will need events recorded explicitly.
• Navigation — activity push and pop transitions, registered automatically at initialization.
• Custom — anything your app records explicitly, with a category, a name and a small data map.

Both buffers ride along inside the session-recording entry attached to each captured exception, carrying start and end timestamps so events can be placed on a timeline. Each channel can be turned off individually.

Deobfuscating release crashes

Release builds run R8, so crash traces arrive with renamed classes and rewritten line numbers. Resolving them needs the build's mapping.txt uploaded to TracePath and a build UUID carried on each report so a trace can be matched to its mapping.

The upload endpoint for symbol artifacts already exists and takes plain multipart HTTP with an upload token, the same token used for JavaScript source maps — see Android symbolication. What is missing is the client end: the Gradle plugin that injects the build UUID and the SDK that reports it. Until the library ships, uploaded mappings have no Android crashes to resolve.

What to do today

The backend your app talks to can be instrumented now with OpenTelemetry — a failing screen is usually a failing endpoint, and the endpoint side is fully supported. Synthetic monitors can watch your API from the outside with no code at all.

If you want cross-platform coverage later, the Flutter and React Native SDKs are planned too, and all of them speak the same wire format, so one TracePath project structure covers every platform.