Skip to content
Android SDK

Android, reported with the whole story.

Reports with the whole story from your Android phone and tablet apps.

Everframe captures a screenshot, console logs and network state and the trail of actions that led to the bug on Android — forwarded to your webhook or our dashboard, ready to act on.

screenshot + annotationsreplay (per app)logsnetwork (opt-in)screen trailcrash reportsdevice

In-app bug reporting for Android

Android runs on thousands of device-and-OS combinations, so the bug one user sees is often invisible on your own hardware. Everframe puts a reporter inside your Android phone and tablet app, letting testers and real users file a complete, structured report the moment something looks wrong — no screen recordings, no vague chat messages.

How capture works on Android

When a user opens the reporter, the Android SDK captures a screenshot of the current screen and collects recent console output (logged through Timber, or written to System.out and System.err), network calls and the trail of screens the user moved through. Composables and views marked sensitive are masked before submission. Everything becomes one envelope and is forwarded to your tools or the dashboard.

Quick capture for your team

Your team doesn’t need the reporter. Link a test Android phone or tablet to yourself once under Project settings → Devices: open Link a device, shake the phone and click the number it shows. From then on a shake files a private draft with the screenshot, replay and logs, and the phone shows “Captured · your name”. You title it on the dashboard. A shared QA device can be linked to the team instead, so its captures land in the inbox. On your users’ devices shake keeps doing what it does today. See Quick capture on real devices.

Ready to act on

The report carries the screenshot, the surrounding log and network state, and the action trail that led to the bug — exactly the context a developer or an AI agent needs to reproduce and fix the bug, not just guess at it.

Android’s own bug report

The platform already has something called a bug report: a device diagnostic dump, not a user’s account of the problem. Android bug report: what it is, where it’s saved and how to read it covers what that dump contains and the gap it leaves.

For crashes specifically — logcat’s crash buffer, ANR traces, native tombstones and retracing an R8 build — see Android crash logs: where to find them and how to read them.

Crash reporting on Android

Uncaught Java and Kotlin exceptions become reports on their own, with the breadcrumb trail and the device, sent on the next launch. On Android 11 and later, native crashes, ANRs and low-memory kills are reported from the exit record the OS keeps. The Gradle plugin uploads R8 mappings and native symbols after each release build, so each stack reads as your source.

What every Android report carries

  • The trail of screens and actions leading up to the report — navigation, taps and errors.
  • A screenshot with the reporter's annotation, masked for PII.
  • Console logs (Timber, System.out and System.err) and OkHttp network calls from the seconds before the report.
  • App, SDK, OS and device metadata.

Install

// gradle.properties
everframeVersion=1.2.1

// build.gradle
implementation("dev.everframe:core:$everframeVersion")
implementation("dev.everframe:reporter-ui:$everframeVersion")

Questions

Does Everframe support Android tablets?

Yes. The Android SDK covers phones and tablets; the report is the same envelope on both.

What is in an Android report?

A structured, typed envelope — screenshot, console logs, network and the action trail that led to the bug — so whoever picks it up starts from evidence, not a guess.

How does my team report bugs without the form?

With quick capture. Link a test Android phone or tablet to yourself under Project settings → Devices in the dashboard, then shake it. A private draft with the screenshot, replay and logs lands in the dashboard's capture card, and you title it there. Your users' release builds don't change.