Documentation Index
Fetch the complete documentation index at: https://launchdarkly-preview.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
This LaunchDarkly observability plugin is currently available in Early Access, and APIs are subject to change until a 1.x version is released.
Overview
This topic documents how to get started with the LaunchDarkly observability plugin for the Android SDK. The Android SDK supports the observability plugin for error monitoring, logging, tracing, and session replay.LaunchDarkly’s SDKs are open source. In addition to this reference guide, we provide source, API reference documentation, and a sample application:
| Resource | Location |
|---|---|
| SDK API documentation | Observability plugin API docs |
| GitHub repository | @launchdarkly/observability-android |
| Published module | Maven |
Prerequisites and dependencies
This reference guide assumes that you are somewhat familiar with the LaunchDarkly Android SDK. The observability plugin is compatible with the Android SDK, version 5.9.0 and later. The LaunchDarkly Android SDK is compatible with Android SDK versions 21 and higher (Android 5.0, Lollipop).Get started
Follow these steps to get started:- Install the plugin
- Initialize the Android SDK client
- Configure the plugin options
- Configure additional instrumentations
- Configure session replay
- Explore supported features
- Review observability data in LaunchDarkly
Install the plugin
LaunchDarkly uses a plugin to the Android SDK to provide observability. The first step is to make both the SDK and the observability plugin available as dependencies. Here’s how:Initialize the client
Next, initialize the SDK and the plugin. To initialize, you need your LaunchDarkly environment’s mobile key and the context for which you want to evaluate flags. This authorizes your application to connect to a particular environment within LaunchDarkly. To learn more, read Initialize the client in the Android SDK reference guide. Here’s how to initialize the SDK and plugin:Configure the plugin options
You can configure options for the observability plugin when you initialize the SDK. The plugin constructor takes an optional object with the configuration details. Here is an example:Advanced configuration options
You can customize the observability plugin with additional options:ObservabilityOptions configuration options are:
- logsApiLevel: Minimum log severity to export. Defaults to
INFO. Set toObservabilityOptions.LogLevel.NONEto disable log exporting. - tracesApi: Controls trace recording. Defaults to enabled. Use
ObservabilityOptions.TracesApi.disabled()to disable all tracing, or setincludeErrors/includeSpansindividually. - metricsApi: Controls metric export. Defaults to enabled. Use
ObservabilityOptions.MetricsApi.disabled()to disable metrics. - instrumentations: Enables or disables specific automatic instrumentations:
crashReporting: Iftrue, automatically reports uncaught exceptions as errors. Defaults totrue.activityLifecycle: Iftrue, automatically starts spans for Android Activity lifecycle events. Defaults totrue.launchTime: Iftrue, automatically measures and reports application startup time as metrics. Defaults tofalse.
- serviceName: The service name for the application. Defaults to “observability-android”.
- serviceVersion: The version of the service. Defaults to the SDK version.
- debug: Enables verbose internal logging and debug functionality. Defaults to
false. - resourceAttributes: Additional resource attributes to include in telemetry data.
- customHeaders: Custom headers to include with OTLP exports.
Configure additional instrumentations
To enable HTTP request instrumentation and user interaction instrumentation, add the following plugin and dependencies to your top level application’s Gradle file.Configure session replay
The Android SDK supports session replay, which captures snapshots of your app’s UI at regular intervals. This allows you to visually review user sessions in LaunchDarkly to better understand user behavior and diagnose issues. To enable session replay, add theSessionReplay plugin to the plugins list after the Observability plugin. Session replay depends on the Observability plugin being present and initialized first.
Here’s how:
SessionReplaydepends onObservability. If Observability is missing or listed after SessionReplay, the plugin logs an error and stays inactive.- Observability runs fine without SessionReplay. Adding SessionReplay extends the Observability pipeline to include session recording.
Initialize the plugins after the SDK client
You can initialize the session replay plugin manually, after the SDK client is initialized. This approach supports feature-flagged rollouts or dynamic initialization after end user consent. Setenabled to false in ReplayOptions, then call LDReplay.start() when you’re ready to begin recording.
First, configure the plugin with enabled = false:
- Feature-flag the rollout of session replay to a subset of end users
- Wait for end user consent before starting data collection
- Dynamically enable session replay based on runtime conditions
- Maintain compliance with privacy regulations
Session replay configuration options
You can customize session replay behavior by passing aReplayOptions object to the SessionReplay constructor:
ReplayOptions configuration options are:
- privacyProfile: Controls how UI elements are masked in the replay. To learn more, read Privacy options.
- capturePeriodMillis: Period between UI captures in milliseconds. Defaults to
1000(1 second). - debug: Enables verbose logging when set to
true. Defaults tofalse.
serviceName and serviceVersion are set in ObservabilityOptions, not in ReplayOptions.
Privacy options
ThePrivacyProfile class controls how UI elements are masked during session replay. Session replay for Android uses Jetpack Compose semantics to identify and mask UI elements. By default, text inputs are masked to protect user privacy.
Here’s how to configure privacy settings:
- maskTextInputs: When
true, masks all text input fields including editable text and paste operations. Defaults totrue. - maskText: When
true, masks all non-input text elements in the UI. Defaults tofalse. - maskBySemanticsKeywords: When
true, masks sensitive views that contain password fields or text matching sensitive keywords. Defaults tofalse.
Sensitive keywords
WhenmaskBySemanticsKeywords is enabled, the SDK automatically masks any Compose UI text or content descriptions containing predetermined keywords. Keywords you specify are not case-sensitive. For the current set of keywords, read PrivacyProfile.
Common privacy configurations
For maximum privacy (recommended for production):Custom masking with ld
Mask In addition to the privacy profile settings, you can explicitly mask individual UI elements by using the.ldMask() modifier. This is useful when you need to mask specific sensitive fields while allowing other content to remain visible.
Masking XML views
For traditional Android XML-based views, you can mask anyView by calling the .ldMask() extension function:
Masking Jetpack Compose elements
For Jetpack Compose, you can add the.ldMask() modifier to any composable to mask it in session replay recordings:
Unmasking elements
You can also explicitly unmask elements that would otherwise be masked by the privacy profile settings using the.ldUnmask() modifier:
.ldMask() and .ldUnmask() modifiers give you fine-grained control over which UI elements are masked in session replay recordings, allowing you to balance privacy protection with useful debugging information.
For more information on session replay configuration, read Configuration for session replay.
Explore supported features
The observability plugin supports the following features. After the SDK and plugins are initialized, you can access these from within your application:- Configuration for client-side observability
- Configuration for session replay
- Errors
- Logs
- Metrics
- Tracing
Review observability data in LaunchDarkly
After you initialize the SDK and observability plugin, your application automatically starts sending observability data back to LaunchDarkly. You can review this information in the LaunchDarkly user interface. To learn how, read Observability. The observability data collected includes:- Error monitoring: Unhandled exceptions, crashes, and manually recorded errors with stack traces
- Logs: Application logs with configurable severity levels and custom attributes
- Traces: Distributed tracing data including span timing, nested operations, and custom instrumentation
- Metrics: Performance metrics, custom counters, histograms, and gauge measurements
- Session data: User session information including lifecycle events and timing
- User error rate and crash frequency
- Application performance metrics such as launch time and session duration
- Feature flag evaluation context and timing
- Custom business metrics recorded through the SDK