Skip to main content

Network events (7.x Beta)

note

Bugsee Android SDK 7.x is currently in beta. APIs and behaviors described on this page may change before the stable 7.0.0 release.

What changed from 6.x​

Network capture is no longer built into the core bugsee-android artifact. There is no generic MonitorNetwork path that auto-hooks HttpURLConnection, and the 6.x helpers — Bugsee.addNetworkLoggingToOkHttpBuilder(...), addNetworkLoggingToOkHttpClient(...), addNetworkLoggingToKtorHttpClient(...), addNetworkLoggingToPicassoDownloader(...), and newOkHttpWrappedWebSocket(...) — have all been removed.

Instead, each HTTP client is its own extension module:

HTTP clientExtension module
OkHttp 3 / 4com.bugsee:bugsee-android-okhttp
Ktor 2.xcom.bugsee:bugsee-android-ktor-2
Ktor 3.xcom.bugsee:bugsee-android-ktor-3
Cronetcom.bugsee:bugsee-android-cronet

When the Bugsee Gradle plugin is applied, it inspects your dependencies { } block and auto-adds the matching extension module whenever it detects OkHttp, Ktor, or Cronet — you do not need to declare these artifacts yourself. Auto-install can be disabled per client through the bugsee { instrumentation { ... } } DSL (okhttp, ktor, cronet flags).

For full upgrade details — including why leaving old wiring calls in place breaks the build — see Migration guide section 5 "Network client integration".

Removing 6.x manual wiring is mandatory

After upgrading, delete every call to Bugsee.addNetworkLoggingToOkHttpBuilder(...), addNetworkLoggingToOkHttpClient(...), addNetworkLoggingToKtorHttpClient(...), addNetworkLoggingToPicassoDownloader(...), and newOkHttpWrappedWebSocket(...) from your code. Those helpers no longer exist in 7.x, so the code will not compile. Even if it did, the 7.x bytecode instrumentation and extension modules already cover the corresponding call sites — leaving the old wiring in would only double up interceptors.

OkHttp​

Add the extension (or let the Gradle plugin auto-add it when it sees OkHttp in your build):

implementation("com.bugsee:bugsee-android-okhttp:7.x.x")

OkHttp capture is fully transparent. The Bugsee Gradle plugin's OkHttpInstrumentation injects BugseeOkHttpInterceptor into every OkHttpClient.Builder.build() call site at compile time. You do not call any wiring API — constructing an OkHttpClient the standard way is enough:

OkHttpClient client = new OkHttpClient.Builder()
    .build();

WebSocket traffic created via OkHttpClient.newWebSocket(...) and image loaders built on top of OkHttp (for example Picasso's OkHttp3Downloader, Retrofit backed by OkHttp, Glide's OkHttp integration) are all captured automatically as a result.

The extension reads Options.CaptureNetwork, Options.CaptureNetworkBodySizeLimit, and Options.CaptureNetworkBodyWithoutType when it launches and honors those settings at runtime.

Ktor 2​

Add the extension (or let the Gradle plugin auto-add it when it detects io.ktor 2.x in your build):

implementation("com.bugsee:bugsee-android-ktor-2:7.x.x")

Ktor capture is not transparent. Ktor's HttpClient only sees plugins that you explicitly install. Each HttpClient instance you create must install BugseeKtor2Plugin. Ktor is a Kotlin-only client, so no Java variant is shown.

val client = HttpClient {
    install(BugseeKtor2Plugin)
    // ... your other plugins
}

BugseeKtor2Plugin takes no configuration. It reads its settings from a process-wide static populated by the SDK, so you pass nothing when installing it. When the SDK is not active, the installed plugin instance no-ops.

Ktor 3​

Add the extension (or let the Gradle plugin auto-add it when it detects io.ktor 3.x in your build):

implementation("com.bugsee:bugsee-android-ktor-3:7.x.x")

Same model as Ktor 2, but targeting Ktor 3.x's createClientPlugin API. The install target is BugseeKtor3Plugin.Plugin — a property exposed on the companion — rather than the class itself. Ktor 3 is Kotlin-only.

val client = HttpClient {
    install(BugseeKtor3Plugin.Plugin)
    // ... your other plugins
}

Cronet​

Add the extension (or let the Gradle plugin auto-add it when it detects Cronet in your build):

implementation("com.bugsee:bugsee-android-cronet:7.x.x")

Cronet capture is not transparent. Cronet has no interceptor pipeline, and its Builder.build() call site lives inside the Cronet artifact where bytecode instrumentation cannot reach it. You must wrap every CronetEngine you create with BugseeCronet.instrument(engine):

CronetEngine engine = BugseeCronet.instrument(
    new CronetEngine.Builder(context).build()
);

instrument(engine) returns a CronetEngineWrapper that delegates every call to the original engine and reports request / redirect / complete / error lifecycle events to the Bugsee network capture pipeline. Wrapping is idempotent — calling instrument(...) on an already-wrapped engine returns the same instance — and the wrapper passes calls through unchanged when the SDK is inactive.

Filtering and redacting network events​

Install a filter to inspect, mutate, or drop network events before they are attached to a report. In 7.x, network filters use the generic single-method EventFilter<T> interface on NetworkEvent. Return the (possibly mutated) event to keep it, or return null to drop it entirely.

Bugsee.setNetworkEventFilter(event -> {
    if (event.getUrl().contains("token")) {
        event.setUrl(redact(event.getUrl()));
    }
    return event; // return null to drop the event
});

Notes on the 7.x shape:

  • The filter is a single-method interface. There is no second-argument completion listener — just return the event (or null).
  • Event types are now NetworkEvent / LogEvent in com.bugsee.library.contracts (renamed from BugseeNetworkEvent / BugseeLog).
  • Mutators (setUrl, setMethod, setBody, headers, etc.) and getNoBodyReason() are preserved from 6.x.
  • The filter applies uniformly to events coming from every network extension — OkHttp, Ktor 2, Ktor 3, and Cronet all feed the same pipeline.

See also the Logs page for the matching setLogEventFilter(...) API and the Migration guide section 6 "Filtering: network and log events" for the full before/after comparison.