Bugsee Android SDK 7.0 — A New Era

We're releasing the beta of Bugsee Android SDK 7.0 — the most significant release in the product's history.

This isn't a point release or a collection of incremental patches. Version 7 is a complete ground-up rewrite: new capture engine, new architecture, new detection mechanisms, and a vastly expanded set of captured data. It's been extensively tested internally, and we're opening it up as beta to gather final real-world signal before general availability.

Here's what's new and why it matters.

Screen Capture, Rebuilt

The capture engine is one of the most critical components of the SDK, and it's received the most significant overhaul.

The new implementation brings full support for foldable devices and multi-display configurations, including secondary screens, external monitors, and presentation displays. Previously, capture was tied to the primary display surface — a limitation that was increasingly visible as foldables and Android TV setups became more common in our customers' user bases.

Beyond display topology, we've redesigned the underlying capture mechanics to be more robust. The new engine captures significantly more screen content than before — including surfaces that the old implementation would silently miss — while being smarter about when and how it captures, reducing unnecessary overhead.

Performance: Lower CPU, Lower Memory

The rewrite gave us the opportunity to profile and eliminate inefficiencies that had accumulated across years of development. The result is measurably lower CPU and memory usage across the board.

One notable change: real-time video encoding has been removed from the hot path. In the previous SDK, encoding was running continuously in the background, which generated both CPU load and logcat noise. The new architecture encodes lazily and silently — which also means cleaner logs during development. If you've ever had to scroll past Bugsee output to find your own log lines, you'll appreciate this immediately.

Behavior Deviation Detection

Bugsee has always captured crashes. The new SDK goes further with a new suite of behavior deviation detection mechanisms:

• ANR detection — more reliable signaling for Application Not Responding events, using improved detection heuristics rather than simple main-thread watchdog polling
• Hang detection — catches situations where the app is alive but unresponsive, even when they don't escalate to a full ANR
• Jank frame detection — surfaces dropped and slow frames, correlated with session timeline and system state at the time
• Process exit tracking — captures the reason for process termination, including cases where the system kills the process without a traditional crash signal (e.g., SIGKILL, ApplicationExitInfo)

These signals are all surfaced as first-class events in the Bugsee timeline, giving you context around what the app was doing before and during each deviation.

First-Class Jetpack Compose Support

SDK 7.0 brings full support for Jetpack Compose — not just basic compatibility, but deep integration with the Compose rendering model.

The SDK correctly captures Compose UI visually, records touch and gesture input within Compose screens, and automatically obscures secure fields (password inputs, sensitive data) in the session video. The same privacy guarantees that existed for the View system now apply natively to Compose, with no extra configuration required.

Compose support is delivered via a dedicated module, keeping the integration clean for apps that haven't migrated yet.

Expanded System Events and Traces

The SDK now captures a far richer picture of what's happening on the device at the time of any issue.

System Events (9 types) are captured as discrete timeline entries:

• Activity lifecycle changes
• Configuration changes (locale, orientation, screen size)
• Keyboard and IME state changes
• Input device connections and disconnections
• Clipboard changes
• Memory warnings and trim events
• Application foreground/background transitions

System Traces (23 types) are recorded as continuous time-series data:

• Display state (on, off, doze)
• WiFi, Bluetooth, and NFC connectivity
• Cellular network status
• CPU usage and thermal state
• RAM and process memory consumption
• FPS (frames per second)
• Screen brightness and orientation
• Power and charging status
• Storage volume changes
• UI mode and contrast settings

All of this is captured continuously and included in bug reports. When you're investigating an issue, you'll have the full environmental context — not just what the app was doing, but what the device was doing around it.

Breadcrumbs (Experimental)

The new SDK includes an optional breadcrumb capture API, currently in beta/experimental status. Breadcrumbs let you annotate the session timeline with arbitrary developer-defined events — navigation steps, feature flags, API call results, or any signal that helps reconstruct what led to a bug.

The API is opt-in and the data format is intentionally flexible. We'll share more details on the breadcrumb API design as we stabilize it through the beta.

Modular Architecture

The SDK is now built around a modular structure where support for additional functionality and third-party integrations lives in dedicated, attachable modules — included only when you need them.

This means integrations that previously required conditional code paths or carried unnecessary weight for projects that didn't use them are now cleanly separated. The currently available modules cover:

• OkHttp — network request capture for OkHttp-based stacks
• Cronet — network capture for apps using Chromium's network stack
• Ktor 2.x and 3.x — separate modules for each major Ktor version
• Compose — Jetpack Compose support

The core SDK handles capture, crash reporting, and the event stream. Everything else is opt-in. Add what your stack actually uses, leave out the rest.

Automatic Initialization via ContentProvider

The new SDK initializes automatically using Android's ContentProvider mechanism. You no longer need to add initialization code to Application.onCreate() — the SDK bootstraps itself at process start, before your application code runs.

This has a few practical benefits:

• Crash coverage from process start: the SDK is live before any of your code executes, so crashes during early initialization are captured
• Less boilerplate: no manual init call, no risk of initializing too late or forgetting to initialize in a custom Application subclass
• Consistent behavior: initialization order is deterministic regardless of how your application is structured

If you need to defer initialization or customize the startup behavior, you'll still be able to opt out of auto-init and call the SDK manually — the ContentProvider approach is the default, not the only option.

Built-in APM

SDK 7.0 ships with a built-in APM framework — and every bug, error, and crash report now comes with full performance context automatically attached.

The APM tracks key performance indicators across six categories:

• UI Performance — screen load times, display times, frame rendering
• Startup Performance — cold and warm launch measurement
• Network Performance — HTTP request latency and bandwidth tracking
• Database Performance — query execution time and transaction tracking
• File I/O — disk read/write operation monitoring
• Custom Spans — define your own transactions and spans for business-critical flows

Performance context propagates automatically across threads, so async operations are correctly attributed to their parent transactions — no manual instrumentation needed for the common case.

Performance data flows through two paths: all transactions are embedded in bug reports for full context at the moment of failure, while sampled transactions are also uploaded independently for standalone performance monitoring. You get both the macro view (how your app performs overall) and the micro view (exactly what was happening when something went wrong) from a single integration.

Try the Beta Release

SDK 7.0 beta is available now. The SDK has been extensively tested, and we're confident in its stability — the beta label reflects an open invitation for real-world validation, not a caveat about production readiness.

Integration docs, module references, and the migration guide from 6.x are available in the Bugsee documentation.

If you run into anything — or have questions about migrating from the previous SDK — reach out via the support chat or email us at support@bugsee.com. We're actively monitoring feedback as we work toward the 7.0 GA release.