Extensions (7.x Beta)

7.x Beta

This page documents the 7.x beta of the Bugsee Android SDK. The extension framework is new in 7.x: capabilities that used to live inside the monolithic AAR (feedback UI, HTTP-client network capture, Compose integration) are now optional modules you pull in only if you need them.

What is an extension?

An extension is an optional Bugsee SDK capability shipped 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

Artifact	Purpose	Documentation
com.bugsee:bugsee-android-feedback	In-app feedback messenger UI.	Feedback
com.bugsee:bugsee-android-okhttp	Transparent network capture for OkHttp 3/4 clients.	Network
com.bugsee:bugsee-android-ktor-2	Network capture plugin for Ktor 2.x HttpClient.	Network
com.bugsee:bugsee-android-ktor-3	Network capture plugin for Ktor 3.x HttpClient.	Network
com.bugsee:bugsee-android-cronet	Network capture via CronetEngine wrapping.	Network
com.bugsee:bugsee-android-compose	Jetpack 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 dependency	Auto-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 — must always be declared explicitly in your dependencies { } block.

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:

build.gradle.kts

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-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
}

build.gradle

dependencies {
    implementation 'com.bugsee:bugsee-android:7.x.x'
    implementation 'com.bugsee:bugsee-android-feedback:7.x.x'
    implementation 'com.bugsee:bugsee-android-okhttp:7.x.x'
    implementation 'com.bugsee:bugsee-android-ktor-2:7.x.x'
    implementation 'com.bugsee:bugsee-android-ktor-3:7.x.x'
    implementation 'com.bugsee:bugsee-android-cronet:7.x.x'
    implementation 'com.bugsee:bugsee-android-compose:7.x.x'
}

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> extensionType, T instance);

Kotlin

import com.bugsee.library.Bugsee
import com.bugsee.library.contracts.extensions.Feedback

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

Java

import com.bugsee.library.Bugsee;
import com.bugsee.library.contracts.extensions.Feedback;

Feedback feedback = Bugsee.ext(Feedback.class);
if (feedback != null) {
    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.

Custom extensions

The extension framework is open — third-party code (including your own app or an internal library) can ship a custom extension that registers itself alongside the first-party ones.

A custom extension is a class that implements the base Extension contract from the core SDK:

package com.bugsee.library.contracts.extensions;

public interface Extension {
    Class<? extends Extension> getType();
    void launch(OptionsContainer options);
    void stop();
}

Your extension defines its own sub-interface that extends Extension, implements a facade class that implements that sub-interface, and registers itself at app startup via a ContentProvider declared in its module's AndroidManifest.xml. Consumers then retrieve it with Bugsee.ext(YourInterface.class) exactly like the first-party extensions.

The authoring rules for a clean extension module — package layout, manifest initOrder, naming conventions, and how to hook into the core SDK's capture/lifecycle/appearance subsystems — ship with the Bugsee Android SDK source tree. Contact Bugsee support if you are building a custom extension and need the detailed authoring guide.