Skip to content

feat: [SDK-2121] implement session replay for react native android#456

Open
beekld wants to merge 3 commits intomainfrom
beeklimt/SDK-2121
Open

feat: [SDK-2121] implement session replay for react native android#456
beekld wants to merge 3 commits intomainfrom
beeklimt/SDK-2121

Conversation

@beekld
Copy link
Copy Markdown

@beekld beekld commented Apr 2, 2026

Summary

This is a fairly straightforward adaptation of the iOS version of the plugin.

How did you test this change?

There are some unit tests, but the primary test was by creating a react native test app, configuring it with my own LD key, and verifying that Android session replay worked the same as iOS session replay.

Are there any deployment considerations?

No.


Note

Medium Risk
Adds a real Android session replay implementation that initializes an offline LDClient with observability/session-replay plugins and new native dependencies; main risk is runtime/initialization and threading behavior on Android plus new SDK version coupling.

Overview
Adds Android support for session replay in @launchdarkly/react-native-ld-session-replay, replacing the previous Android "not supported" stubs.

Introduces a native SessionReplayClientAdapter that configures an offline LDClient with Observability + SessionReplay plugins (main-thread init, simple start/stop state machine), maps JS options into ReplayOptions/PrivacyProfile, and wires these behaviors through the React Native module (configure, startSessionReplay, stopSessionReplay) with basic validation/error handling.

Updates Android Gradle config to include LaunchDarkly observability + Android SDK dependencies and JUnit5/MockK test setup, and adds unit tests for option mapping/start preconditions plus JS tests ensuring configure/startSessionReplay are invoked on plugin registration; also adds a no-op getHooks() to satisfy the LDPlugin interface.

Written by Cursor Bugbot for commit 7ba6e77. This will update automatically on new commits. Configure here.


Related Jira issue: SDK-2121: Implement Session Replay for React Native Android.

@launchdarkly-upra launchdarkly-upra bot changed the title feat: implement session replay for react native android feat: [SDK-2121] implement session replay for react native android Apr 2, 2026
@beekld beekld marked this pull request as ready for review April 2, 2026 16:04
@beekld beekld requested a review from a team as a code owner April 2, 2026 16:04
mobileKey = mobileKey,
options = ObservabilityOptions(
serviceName = serviceName,
sessionBackgroundTimeout = 10.minutes,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be internal default.

For next PRs: SessionReplay inherit some settings from ObservabilityOptions:
resourceAttributes
sessionBackgroundTimeout
backendUrl

they should be transfered here


// The context key is a placeholder — the LDClient is offline and never sends it to
// LaunchDarkly servers. The React Native LDClient manages the real user context.
val context = LDContext.builder(ContextKind.DEFAULT, "12345").build()
Copy link
Copy Markdown
Contributor

@abelonogov-ld abelonogov-ld Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment is not completelly true

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SessionReplay uses data from context to send data to server. Do you have other way of passing context currently implemented.

// calls lifecycle.addObserver() internally, which requires the main thread.
// Using timeout=0 so we don't block the UI — onPluginsReady() fires
// synchronously during LDClient.init() regardless of the flag-fetch timeout.
Handler(Looper.getMainLooper()).post {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why State Machine this logic exists here, I hope it wasn't here.

but if needed it has some race conditions.

  • currentState is checked outside lock
  • later state is being updated outside lock
  • state is being modified without @volatile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants