Lifecycle events

The SDK can be launched, stopped, and re-launched at runtime, and exposes a listener for internal state transitions (report uploads, blackouts, crash relaunches).

Launch, stop, and relaunch

In 7.0, launch, stop, and relaunch each offer an optional async completion callback invoked on the background pool thread when the operation has fully applied. The synchronous overloads still exist.

Java

// Launch (only needed if no token in AndroidManifest.xml)
Bugsee.launch("<app-token>");
Bugsee.launch(context, "<app-token>");
Bugsee.launch(context, "<app-token>", options);
Bugsee.launch(context, "<app-token>", options, success -> { /* async */ });
// Stop
Bugsee.stop();
Bugsee.stop(() -> { /* fully stopped */ });
// Relaunch (stop + launch, preserves token)
Bugsee.relaunch();
Bugsee.relaunch(newOptions);
Bugsee.relaunch(success -> { /* ... */ });
Bugsee.relaunch(newOptions, success -> { /* ... */ });

Kotlin

// Launch
Bugsee.launch("<app-token>")
Bugsee.launch(context, "<app-token>")
Bugsee.launch(context, "<app-token>", options)
Bugsee.launch(context, "<app-token>", options) { success -> /* async */ }
// Stop
Bugsee.stop()
Bugsee.stop { /* fully stopped */ }
// Relaunch
Bugsee.relaunch()
Bugsee.relaunch(newOptions)
Bugsee.relaunch { success -> /* ... */ }
Bugsee.relaunch(newOptions) { success -> /* ... */ }

If your app declares the token in AndroidManifest.xml, the SDK auto-launches at process start via a ContentProvider — no explicit launch call is needed. See Installation.

Querying launch state

Bugsee.getLaunched() returns whether the SDK is currently launched and active. It's useful when your code path can run before auto-init or a programmatic launch has completed, or after a stop() — for example, to guard a call into an API that only does something while the SDK is running.

Java

if (Bugsee.getLaunched()) {
    // SDK is running — safe to use runtime-only APIs.
}

Kotlin

if (Bugsee.getLaunched()) {
    // SDK is running — safe to use runtime-only APIs.
}

getLaunched() returns true between a successful launch (or auto-init) and the next stop, and false otherwise. Most public APIs already no-op safely when the SDK isn't running, so this check is for cases where you want to skip work explicitly rather than rely on that. If you also want to observe the moment the state flips, register a lifecycle listener and watch for the Launched / Stopped events described below.

Blackout windows

Bugsee.startBlackout() / endBlackout() bracket a window where video is blanked and touches are dropped. Use them to hide a sensitive screen or flow from capture without stopping the SDK. To fully shut the SDK down, use Bugsee.stop() / Bugsee.launch() instead.

Lifecycle event listener

Register a listener with setLifecycleEventsListener to observe internal SDK transitions. The callback receives an event-type string and optional data payload, and is invoked on a background thread.

Java

Bugsee.setLifecycleEventsListener((eventType, data) -> {
    if (LifecycleEvents.RelaunchedAfterCrash.equals(eventType)) {
        // previous session ended with a crash
    }
});

// Unsubscribe
Bugsee.setLifecycleEventsListener(null);

Kotlin

Bugsee.setLifecycleEventsListener { eventType, data ->
    if (eventType == LifecycleEvents.RelaunchedAfterCrash) {
        // previous session ended with a crash
    }
}

// Unsubscribe
Bugsee.setLifecycleEventsListener(null)

Event-type strings are declared as constants on com.bugsee.library.contracts.lifecycle.LifecycleEvents:

Constant	Description
Launched / Stopped	SDK has launched / stopped.
BlackoutStarted / BlackoutEnded	Visual capture paused / resumed by startBlackout() / endBlackout().
RelaunchedAfterCrash	SDK launched and a pending crash from a previous session was discovered.
BeforeReportShown / AfterReportShown	Reporting UI is about to be / has been shown.
BeforeReportAssembled / AfterReportAssembled / ReportAssemblyFailed	Report assembly stages.
BeforeReportUploaded / AfterReportUploaded	Report upload start / success.
ReportUploadFailedWithFutureRetry / ReportUploadFailed	Upload failed (retryable / permanent).

Feedback-specific events (e.g. BeforeFeedbackShown, AfterFeedbackShown) are declared on FeedbackLifecycleEvents (in the same package) and dispatched only when bugsee-android-feedback is on the classpath.

Extension lifecycle

Extension modules (feedback, OkHttp, Ktor, Cronet, Compose, etc.) receive their own launch(options) and stop() callbacks automatically when the SDK starts and stops — they are wired through the same Bugsee.launch / Bugsee.stop entry points and need no separate initialization from your code. See Bugsee extensions for details.