Bugsee Android SDK 7.0 — Now Generally Available

Bugsee Android SDK 7.0 is now generally available. After an extended beta, the most significant release in the product's history is ready for production.

Version 7 is a complete ground-up rewrite — a new capture engine, a broader detection suite, built-in performance monitoring, and a modular architecture — built to run across every kind of Android device while doing more with a smaller footprint. Here is what is in it, and why it matters.

One SDK for every Android device

7.0 runs on the full range of Android form factors from a single artifact and the same setup: phones, tablets, Wear OS wearables, Android TV, and Android Automotive OS. There is no separate build, no per-device dependency, and no special configuration — the SDK detects the platform and adapts at runtime.

Capture, issue detection, report assembly, and upload behave the same way on a watch or a car head unit as they do on a phone. We validated each non-phone form factor end to end ahead of release.

A capture engine rebuilt from scratch

Screen capture — the most critical part of the SDK — received the deepest overhaul.

The new engine captures every kind of on-screen component, including the surface types the previous implementation could silently miss: SurfaceView, GLSurfaceView, video and map surfaces, and hardware-accelerated content. It composites the full window stack into each frame, so the session video matches what the user actually saw.

It also brings full multi-display support — each display is recorded by its own capture pipeline, so secondary screens, external monitors, and presentation displays are captured, not just the primary one — and full foldable support, adapting cleanly as screen geometry changes on fold and unfold.

Privacy controls apply throughout: secure views and regions are redacted before a frame is ever stored.

First-class Jetpack Compose support

7.0 brings deep Jetpack Compose integration — not just basic compatibility. The SDK captures Compose UI visually, records touch and gesture input on Compose screens, and automatically obscures secure fields such as password inputs in the session video. The same privacy guarantees the View system has always had now apply natively to Compose, with no extra configuration.

Compose support ships as a dedicated module, so apps that have not adopted Compose carry none of its weight.

Performance context on every report

Every bug, crash, and error report now arrives with full performance data automatically attached, courtesy of a built-in APM (Application Performance Monitoring) framework.

Out of the box it measures app startup (cold and warm), screen load and render times, network-request latency, database queries, and file I/O. Performance context propagates across threads automatically, so asynchronous work is attributed to the right transaction without manual wiring. When you need it, you can open your own custom spans and transactions around business-critical flows.

The result: when something goes wrong, you do not just see the failure — you see exactly how the app was performing in the moments around it.

Detection that goes beyond crashes

Bugsee has always captured crashes. 7.0 adds a much broader detection suite for the problems that never throw an exception:

• ANRs — detected from the same system data source as the Google Play Console, so the ANR events and rates you see in Bugsee line up with Play.
• Hangs — the app is alive but unresponsive, even when it never escalates to a full ANR.
• Abnormal process exits — terminations the system performs without a crash signal, including low-memory kills, captured with the reason.
• Main-thread misuse — disk and network work on the UI thread that quietly causes jank.
• User-frustration signals — rage taps, error taps, and stuck-loading states that flag a problem from the user's side.

Frame rate is tracked continuously, so janky and dropped frames surface on the session timeline alongside everything else.

On-device memory leak detection

A new, optional leak-detection module watches for memory that should have been released but was not — retained activities, fragments, and other objects — and flags suspected leaks together with the reference chain keeping them alive. It detects leaked threads too. Analysis runs entirely on the device; raw heap dumps never leave it.

Because it is a separate module, you opt in by adding it, and it stays out of builds that do not need it.

More robust native crash reporting

Native (NDK) crash interception has been rebuilt on a new, more capable out-of-process handler. It captures native crashes more reliably and produces higher-quality, more complete native stack traces — even in the hostile conditions that follow a memory-corruption crash. Like everything else optional in 7.0, native crash reporting is a module you add when you need it.

A fuller picture of the device

7.0 records a far richer set of system events and continuous traces than before, so every report carries the surrounding context — not just what your app was doing, but what the device was doing around it.

System events capture discrete moments: activity lifecycle, configuration changes (orientation, locale, screen size), keyboard and IME state, input-device connect and disconnect, clipboard changes, memory-trim warnings, and foreground/background transitions. Continuous traces sample the environment over time: connectivity (Wi-Fi, cellular, Bluetooth, NFC), CPU and thermal state, RAM and process memory, frame rate, display state, screen brightness and orientation, power and charging, storage, and UI mode.

Breadcrumbs (experimental)

New in 7.0 — and currently experimental — breadcrumbs let you annotate the session timeline with your own structured events: navigation steps, feature-flag states, business checkpoints, or any signal that helps reconstruct what led to a bug. They sit alongside the SDK's built-in system events, carry arbitrary additional data, and can be filtered or redacted before they are recorded. We will keep refining the API as it stabilizes.

A new Gradle plugin, and zero-setup initialization

7.0 introduces a dedicated Bugsee Gradle plugin that brings integration friction close to zero. It auto-adds the SDK and the optional modules you enable, and it instruments your app at build time to improve both the quality and the quantity of captured data — wiring up performance monitoring, log capture, network interception, and Compose privacy controls without hand-written glue code.

The SDK also initializes itself automatically at process start through a ContentProvider, before any of your code runs. There is no init call in Application.onCreate(), which means crashes during early startup are covered and there is nothing to forget. Manual initialization remains available if you need to defer or customize it.

Lighter, by design

For all the new capability, 7.0 is leaner than its predecessor. The rewrite was an opportunity to profile and remove inefficiencies accumulated over years, and to take real-time video encoding off the hot path — which also means dramatically less logcat noise during development. The net result is measurably lower CPU and memory use, and we publish the actual startup-overhead and memory figures for low- and high-end devices in the documentation so you can see the numbers for yourself.

A redesigned Feedback experience

The in-app feedback messenger — which lets your users chat directly with your team — has been rebuilt with a new, modern UI and now ships as its own optional module. Add it when you want it; leave it out when you do not.

Available now

Bugsee Android SDK 7.0 is generally available today. Integration guides, module references, the device-support overview, and the 6.x to 7.x migration guide are all in the Bugsee documentation.

Upgrading from 6.x, or starting fresh? If you run into anything — or just want a hand planning the migration — reach out via the in-app chat or email support@bugsee.com.