Skip to main content

Bugsee extensions (7.x Beta)

7.x Beta

This page documents the 7.x beta of the Bugsee Android SDK. Capabilities that used to live inside the monolithic 6.x AAR — feedback UI, HTTP-client network capture, Compose integration — are now optional modules you pull in only if you need them.

What is a Bugsee extension?

A Bugsee extension is an optional SDK capability shipped by Bugsee as a separate Gradle module. There is no manual initialization code: each extension module ships its own ContentProvider that the Android manifest merger pulls into your app, and that provider registers the extension with the core SDK at process startup.

In practice this means adding the Gradle dependency is all that's needed. When Bugsee.launch(...) runs, every registered extension is launched automatically; when Bugsee.stop() runs, they are stopped.

Extensions are keyed in the SDK registry by their contract interface type (for example Feedback, OkHttpCapture), not by their concrete facade class. You retrieve them at runtime with Bugsee.ext(Interface.class).

First-party extensions

ArtifactPurposeDocumentation
com.bugsee:bugsee-android-feedbackIn-app feedback messenger UI.Feedback
com.bugsee:bugsee-android-ndkNative (NDK) crash detection via Crashpad, with ApplicationExitInfo matching.Native crashes
com.bugsee:bugsee-android-leakMemory- and thread-leak detection via watch-source instrumentation and Shark heap dumps.Memory & thread leaks
com.bugsee:bugsee-android-okhttpTransparent network capture for OkHttp 3/4 clients.Network
com.bugsee:bugsee-android-ktor-2Network capture plugin for Ktor 2.x HttpClient.Network
com.bugsee:bugsee-android-ktor-3Network capture plugin for Ktor 3.x HttpClient.Network
com.bugsee:bugsee-android-cronetNetwork capture via CronetEngine wrapping.Network
com.bugsee:bugsee-android-composeJetpack Compose integration — Modifier.bugseeSecure() and Compose input capture.Video privacy

Each extension has its own dedicated page with setup details and the API it exposes.

Auto-install via the Bugsee Gradle plugin

When the Bugsee Gradle plugin is applied, it inspects your project's implementation configuration during withDependencies and automatically adds the matching Bugsee extension artifact at the same version as the plugin whenever it detects a known third-party dependency:

Detected dependencyAuto-added Bugsee module
androidx.compose.*com.bugsee:bugsee-android-compose
com.squareup.okhttp3:*com.bugsee:bugsee-android-okhttp
io.ktor:* (2.x)com.bugsee:bugsee-android-ktor-2
io.ktor:* (3.x)com.bugsee:bugsee-android-ktor-3
org.chromium.net:*com.bugsee:bugsee-android-cronet

If you already declared the matching artifact yourself, the plugin leaves your declaration alone. Each auto-install rule can be disabled individually via the bugsee { instrumentation { … } } DSL block (okhttp, ktor, cronet, compose). See the Gradle plugin reference for the full list.

Auto-install only covers artifacts that are dependency-driven. Extensions with no corresponding third-party trigger — notably bugsee-android-feedback and bugsee-android-ndk — must always be declared explicitly in your dependencies { } block.

Core SDK pulled by extension declaration

When the Bugsee Gradle plugin is applied, declaring only an extension is sufficient — the plugin auto-pulls the matching com.bugsee:bugsee-android core SDK if it isn't already declared. So either of these is a complete setup:

dependencies {
implementation("com.bugsee:bugsee-android-feedback:7.x.x")
// core SDK auto-pulled by the Bugsee Gradle plugin
}
dependencies {
implementation("com.bugsee:bugsee-android:7.x.x")
implementation("com.bugsee:bugsee-android-feedback:7.x.x")
// both declared explicitly — the plugin sees the core is present and skips auto-load
}

The auto-pulled version is the latest patch of the same MAJOR.MINOR series the plugin was released against (e.g. [7.0.0-beta12, 7.1.0)), so you pick up patch updates without bumping the plugin and never silently cross a minor boundary. Opt out via bugsee { sdkAutoLoad.set(false) } if you ship the core SDK from a manual classpath path or a locally-published artefact — see the Gradle plugin reference.

For OkHttp, installation is fully transparent: the plugin's bytecode instrumentation injects the Bugsee interceptor at every OkHttpClient.Builder.build() call site. For Ktor 2 / Ktor 3 / Cronet, the plugin adds the artifact but your code still needs an explicit install(BugseeKtorPlugin...) / BugseeCronet.instrument(engine) call — these clients do not expose a transparent interception point.

Without the Bugsee Gradle plugin

If you are not using the Bugsee Gradle plugin (for example, a Maven-based build or a Gradle project where you chose not to apply the plugin), none of the auto-install rules run. Every extension module you want — network capture, Compose integration, feedback — must be declared explicitly as a dependency:

dependencies {
implementation("com.bugsee:bugsee-android:7.x.x") // core (required)
implementation("com.bugsee:bugsee-android-feedback:7.x.x") // optional
implementation("com.bugsee:bugsee-android-ndk:7.x.x") // optional — native crash capture
implementation("com.bugsee:bugsee-android-okhttp:7.x.x") // optional
implementation("com.bugsee:bugsee-android-ktor-2:7.x.x") // optional
implementation("com.bugsee:bugsee-android-ktor-3:7.x.x") // optional
implementation("com.bugsee:bugsee-android-cronet:7.x.x") // optional
implementation("com.bugsee:bugsee-android-compose:7.x.x") // optional
}

Remember that a number of 7.x capabilities additionally require the Gradle plugin's bytecode / Kotlin-compiler instrumentation and are not available at all in builds that skip the plugin (APM DB/file-I/O spans, main-thread misuse detection, transparent OkHttp interception, Compose secure-modifier auto-injection, mapping/NDK-symbol upload). See the Maven installation page for the full list of plugin-gated features.

Retrieving an extension at runtime

Bugsee.ext(Class) returns the registered extension facade cast to its contract interface, or null if the extension module is not on the classpath. Always null-check the result — your app must still build and run when an optional extension is excluded.

The exact signatures on Bugsee:

static <T extends Extension> T ext(Class<T> extensionType);
static <T extends Extension> void registerExt(Class<T> extInterface, Extension extension);
import com.bugsee.library.Bugsee
import com.bugsee.library.contracts.extensions.Feedback

val feedback = Bugsee.ext(Feedback::class.java)
feedback?.showFeedbackActivity()

The type parameter is always the contract interface (Feedback, OkHttpCapture, Ktor2Capture, Ktor3Capture, CronetCapture, ...), never a Bugsee… facade class.

Extension lifecycle

Extensions participate in the core SDK lifecycle automatically:

  • Bugsee.launch(...) — every registered extension has its launch(OptionsContainer) called. An extension reads the options it cares about (for example Options.CaptureNetwork) from the shared options container.
  • Bugsee.stop() — every registered extension has its stop() called. The extension remains registered and will be launched again on the next Bugsee.launch(...).
  • Bugsee.relaunch(...) — equivalent to a stop/launch cycle for extensions.

Each extension's launch / stop call is isolated: a failure in one extension never affects the others or the core SDK.

Writing your own

The extension framework is open: anything Bugsee ships, you can ship too. For instructions on authoring your own generic extension module, custom capture provider, custom detection provider, or custom APM provider, see Custom extensions.

Found an issue, typo, or wrong statement on this page? Report it now →