Issue detection — Overview
The detection subsystem is new in 7.0.0. Several detectors are off by default and must be explicitly enabled.
7.0.0 introduces a dedicated detection subsystem that observes the running app and turns behavior deviations into Bugsee issue reports. Each detector is an independent provider — enable or disable any of them in isolation without affecting the rest of the SDK.
Built-in detectors
| Detector | What it observes | Default | Documentation |
|---|---|---|---|
| Crashes | Uncaught JVM (Java / Kotlin) exceptions | On | Crashes |
| Hangs | Main-thread stalls long enough to degrade UX, but short enough that the OS hasn't raised an ANR | Off | Hangs |
| Exits | Process terminations reported by ActivityManager.getHistoricalProcessExitReasons() — ANRs, low-memory kills, dependency death, and more | On (master) / per-reason mix | Exits |
| Main-thread misuse | Blocking I/O, network, DB, or SharedPreferences work performed on the UI thread | Off | Main-thread misuse |
| HTTP errors | 5xx server responses surfaced as standalone issues | Off | HTTP errors |
| Anomaly | Per-bucket statistical outliers over completed APM transactions | Off | Anomaly |
| Frustration | UX-frustration patterns: rage taps, error taps, stuck loading, frozen UI | Off | Frustration |
Extension-shipped detectors
| Detector | Extension | What it observes | Default | Documentation |
|---|---|---|---|---|
| Native crashes | bugsee-android-ndk | Native (NDK) crashes via Crashpad, with ApplicationExitInfo tombstone matching | On (when module present) | Native crashes |
| Memory leaks | bugsee-android-leak | Retained Activity / Fragment / ViewModel / Compose nodes via watch-source instrumentation; Shark heap-dump for deep modes | On (when module present) | Leaks |
| Thread leaks | bugsee-android-leak | Thread-group growth over time as a proxy for leaking ThreadPoolExecutor / unbounded task scheduling (Java-only Phase 1) | Off | Leaks |
Extension detectors register themselves with the detection coordinator at process start via their module's ContentProvider — adding the Gradle dependency (or DSL toggle, for ndk / leak) is the only setup required.
How options work
Every detector is gated by a single Options.* constant from com.bugsee.library.contracts.options. The same string key can be set in two equivalent ways:
- As
AndroidManifest.xmlmeta-data —<meta-data android:name="com.bugsee.option.detect.hang" android:value="true" />under<application>. - As an entry in the
Bugsee.launch(...)options map —options.put(Options.DetectAndReportHang, true).
Programmatic values take precedence over manifest values, so a meta-data default can be overridden at launch time per-build-flavor / per-environment. See Configuration for the full options pipeline.
All detection option keys
The authoritative table of detection option keys — Options constants, manifest keys, types, and defaults — lives in the Configuration → Detection reference, alongside the core options for capture, reporting, and APM. Extension-specific options are documented on the matching extension pages: NDK options and Leak options.