Session Replay Android Plugin

Install Session Replay with the Android SDK plugin when your app is already instrumented with Amplitude. If you use a different provider for in-product analytics, use the standalone implementation instead.

Session Replay captures changes to an app's view tree. The view tree includes the main view and all child views recursively. Session Replay then replays these changes to build a video-like replay.

For example, at the start of a session, Session Replay captures a full snapshot of the app's view tree. As the user interacts with the app, Session Replay captures each change to the view as a diff. Session Replay then constructs the replay of the session by applying each diff to the original view tree in sequential order.

Session replays have no maximum length.

Prerequisites

The method you use depends on the version of the Amplitude Android SDK you use.

Supported Android versions

Session replay supports down to Android 5.0 with a minimum SDK of 21 minSdk = 21. This should support over 99.6% of global Android devices according to Google's distribution data in Android Studio.

Quickstart

// Install latest version from Maven Central
implementation("com.amplitude:plugin-session-replay-android:0.31.1")
// You will also need the Amplitude Analytics SDK if it's not already installed
implementation("com.amplitude:analytics-android:[1.30.0,2.0.0)")

import com.amplitude.android.Amplitude
import com.amplitude.android.Configuration
import com.amplitude.android.plugins.SessionReplayPlugin

// Initialize Amplitude Analytics SDK instance
val amplitude = Amplitude(API_KEY, applicationContext)

// Create and Install Session Replay Plugin
// Recording will be handled automatically
val sessionReplayPlugin = SessionReplayPlugin(
    context = applicationContext,
    sampleRate = 1.0
)
amplitude.add(sessionReplayPlugin)

Configuration

Pass the following options when you initialize the Session Replay plugin.

Custom session IDs

Session Replay for Android version 0.26.4 and later supports string session IDs, for example UUIDs, through the setCustomSessionId method. Use a custom session ID if your project defines sessions with a custom event property instead of the Amplitude session_id.

When you set a custom session ID, the value takes precedence over the session ID that the plugin syncs from the Amplitude SDK. Pass null to clear the override and resume using the Amplitude session ID.

// Keep a reference to the plugin to set the custom session ID
val sessionReplayPlugin = SessionReplayPlugin(
    context = applicationContext,
    sampleRate = 1.0
)
sessionReplayPlugin.setCustomSessionId("ef197fc7-a46f-4e6c-a77f-8d90c17065c0")
amplitude.add(sessionReplayPlugin)

// Whenever your custom session changes
sessionReplayPlugin.setCustomSessionId(newCustomSessionId)

For Session Replay to match custom sessions reliably, custom session IDs must follow these constraints:

• The value can't contain /. Session Replay uses / as a delimiter in the session replay ID, which has the format <deviceId>/<sessionId>.
• The value can only contain the characters a-z A-Z 0-9 _ - . | @ : =.
• The value must match the session-defining property you send on events to Amplitude. For more information, refer to Session matching.

Remote configuration

Enable remote configuration to set Sample Rate and Masking Level in Amplitude.

Mask on-screen data

The Session Replay SDK offers four ways to mask user input, text, and other view components.

Mask level

Session Replay for Android supports three levels of masking, set through the privacyConfig option with PrivacyConfig(maskLevel = MaskLevel.MEDIUM). The default level is medium.

Use this option in the Session Replay configuration.

Privacy tags in layout XML

Use this option in your application's layout XML.

Privacy methods on the Session Replay SDK

Import the SessionReplay class, then call one of the methods below from your application's code.

import com.amplitude.android.sessionreplay.SessionReplay

Privacy modifiers in Jetpack Compose

For composables, use the privacy modifiers instead of layout XML tags or the SessionReplay methods. These modifiers require version 0.21.0 or higher of the Session Replay Android SDK or plugin.

Import the modifier you need from com.amplitude.android.sessionreplay.compose, then add it to the composable's modifier chain.

import com.amplitude.android.sessionreplay.compose.ampMask
import com.amplitude.android.sessionreplay.compose.ampUnmask
import com.amplitude.android.sessionreplay.compose.ampBlock

// Mask text that Session Replay captures by default
Text(
    text = "Account number: 123456789",
    modifier = Modifier.ampMask(),
)

// Unmask an input field that Session Replay masks by default
TextField(
    value = username,
    onValueChange = { username = it },
    modifier = Modifier.ampUnmask(),
)

// Block a composable and everything it contains
Box(modifier = Modifier.ampBlock()) {
    Text("Session Replay doesn't capture this content")
}

A privacy modifier applies to the composable you add it to and to everything nested inside it. When a nested composable has its own privacy modifier, that modifier takes precedence for that composable and its descendants.

User opt-out

The Session Replay plugin follows the Android SDK's optOut setting. You can also call setOptOut and getOptOut directly on the plugin instance to pause or resume capture at runtime without restarting the SDK.

// Control opt-out through the Amplitude SDK
val amplitude = Amplitude(Configuration(
    apiKey = API_KEY,
    optOut = true,
    /* other configuration */
))
val sessionReplayPlugin = SessionReplayPlugin(
    context = applicationContext,
    /* session replay options */
)
amplitude.add(sessionReplayPlugin)

// Or pause and resume capture directly on the plugin instance
sessionReplayPlugin.setOptOut(true)   // pause
sessionReplayPlugin.setOptOut(false)  // resume

EU data residency

Session Replay is available to Amplitude Customers who use the EU data center. Set the serverZone configuration option to EU during initialization. For example:

// Set serverZone on the Amplitude SDK
val amplitude = Amplitude(Configuration(
    apiKey = API_KEY,
    serverZone = ServerZone.EU,
    /*, other configuration */
))
amplitude.add(SessionReplayPlugin(
    context = applicationContext,
    /* session replay options */
))

Sampling rate

By default, Session Replay captures 0% of sessions for replay. Use your SDK's sampleRate configuration option to set the proportion of sessions to capture.

For manual and dynamic sampling, quota planning, and quota accounting, go to Configure Session Replay sampling.

// This configuration samples 1% of all sessions
amplitude.add(SessionReplayPlugin(
    context = applicationContext,
    sampleRate = 0.01
))

Disable replay collection

After you enable Session Replay, it runs on your app until either:

• The user leaves your app.
• You call sessionReplayPlugin.stop().
• You remove the plugin from the SDK with amplitude.remove(sessionReplayPlugin).

Call sessionReplayPlugin.stop() before a user navigates to a restricted area of your app to disable replay collection while the user is in that area.

Call sessionReplayPlugin.start() to re-enable replay collection when the user returns to an unrestricted area of your app.

To capture only specific screens, initialize the plugin with autoStart = false so it doesn't start on launch, then call start() and stop() as the user enters and leaves those screens:

// Add the plugin without starting capture
val sessionReplayPlugin = SessionReplayPlugin(
    context = applicationContext,
    sampleRate = 1.0,
    autoStart = false
)
amplitude.add(sessionReplayPlugin)

// Start capture when the user enters a screen you want to record
sessionReplayPlugin.start()

// Stop capture when the user leaves that screen
sessionReplayPlugin.stop()

You can also use a feature flag product like Amplitude Experiment to enable or disable replay collection based on criteria like location. For example, you can create a feature flag that targets a specific user group, then add it to your initialization logic:

import com.amplitude.android.Amplitude
import com.amplitude.android.Configuration
import com.amplitude.android.plugins.SessionReplayPlugin

// Your existing initialization logic with Android SDK
val amplitude = Amplitude(Configuration(apiKey = API_KEY /*, ... other configuration */))

if (nonEUCountryFlagEnabled) {
  // Create and Install Session Replay Plugin
  val sessionReplayPlugin = SessionReplayPlugin(
      context = applicationContext,
      sampleRate = 0.5
  )
  amplitude.add(sessionReplayPlugin)
}

WebView and MapView support (Beta)

By default, Session Replay blocks web views and map views in a capture. To enable capture of these components, use the settings described in Mask on-screen data.

Web view session replay injects JavaScript into the rendered page. To enable this, the SDK sets javaScriptEnabled to true on the unmasked web view.

Log Recording

Session Replay supports recording logs in Android applications. To enable log recording, send log messages through the recordLog(level, message, timestamp) API and configure the limits through recordLogOptions parameter while initializing Session Replay.

import com.amplitude.android.plugins.SessionReplayPlugin
import com.amplitude.android.sessionreplay.config.RecordLogLevel
import com.amplitude.android.sessionreplay.config.RecordLogOptions

val sessionReplayPlugin = SessionReplayPlugin(
    recordLogOptions = RecordLogOptions(
        logCountThreshold = 2000,
        maxMessageLength = 4000
    )
)
amplitude.add(sessionReplayPlugin)

sessionReplayPlugin.recordLog(RecordLogLevel.Error, "This is an error log")

// You can also create custom log levels
sessionReplayPlugin.recordLog(RecordLogLevel("debug"), "This is a debug log")

Session Replay supports predefined log levels (Error, Warn, Log) and custom log levels. Create custom log levels by passing any string value to RecordLogLevel(...).

If you have implemented a log system, you can make single-point modifications to integrate log recording functionality. See the following examples for more information.

Timber

If you use Timber, you can integrate it with a custom tree.

import com.amplitude.android.plugins.SessionReplayPlugin
import com.amplitude.android.sessionreplay.config.RecordLogLevel
import timber.log.Timber

class AmplitudeLogRecordTree(private val plugin: SessionReplayPlugin) : Timber.Tree() {
    override fun log(priority: Int, tag: String?, message: String, t: Throwable?) {
        val recordLevel = when (priority) {
            android.util.Log.ERROR -> RecordLogLevel.Error
            android.util.Log.WARN -> RecordLogLevel.Warn
            android.util.Log.INFO -> RecordLogLevel.Log
            android.util.Log.DEBUG -> RecordLogLevel("debug")
            android.util.Log.VERBOSE -> RecordLogLevel("verbose")
            else -> return
        }
        plugin.recordLog(recordLevel, message)
    }
}

val sessionReplayPlugin = SessionReplayPlugin()
amplitude.add(sessionReplayPlugin)

Timber.plant(AmplitudeLogRecordTree(sessionReplayPlugin))

Data retention, deletion, and privacy

Review consent guidance when you implement capture.

Retention period

For native and Flutter SDK retention guidance and the effective date of changes, go to the Session Replay data lifecycle reference.

DSAR API

For replay metadata returned by the DSAR API, go to Session Replay DSAR metadata.

Data deletion

For user and project deletion behavior, go to Session Replay data deletion.

Bot filter

For bot filtering and property-filter restrictions, go to Session Replay bot filtering.

Session Replay storage

If a user opts out of tracking in your app, use the optOut configuration option to disable replay collection for that user.

The SDK stores replay data locally. It retries transient upload failures, subject to retry and storage limits.

Amplitude recommends setting flushEventsOnClose = true in the Amplitude SDK Configuration (the default) to send session data to the server on each app exit.

Jetpack Compose Support (Alpha)

Session Replay supports Jetpack Compose for Android applications. This feature is currently in Alpha. To use Jetpack Compose with Session Replay, ensure you use version 0.20.4 or higher of the Session Replay Android SDK or plugin.

To control what Session Replay captures in a composable, use the privacy modifiers in Jetpack Compose. Masking support for Compose requires 0.21.0 or higher.

Known limitations

Keep the following limitations in mind as you implement Session Replay:

• Session Replay doesn't stitch together replays from a single user across multiple projects. For example:

  • You instrument multiple apps as separate Amplitude projects with Session Replay enabled in each.
  • A known user begins on one app, and then switch to another.
  • Amplitude captures both sessions.
  • The replay for each session is available for view in the corresponding host project.

• The User Sessions chart doesn't show session replays if your organization uses a custom session definition.

• Session Replay can't capture the following Android views:

  • Canvas Views

Multiple Amplitude instances

Session Replay supports attaching to a single instance of the Amplitude SDK. If you have more than one instance instrumented in your application, start Session Replay on the instance that most relates to your project.

Troubleshooting

For more information about individual statuses and errors, see the Session Replay Ingestion Monitor. |

Replay length and session length don't match

In some scenarios, the length of a replay may exceed the time between the [Amplitude] Start Session and [Amplitude] End Session events. This happens when a user closes the [Amplitude] End Session occurs, but before the Android SDK and Session Replay plugin can process it. When the user uses the app again, the SDK and plugin process the event and send it to Amplitude, along with the replay. You can verify this scenario occurs if you see a discrepancy between the End Session Client Event Time and the Client Upload Time.

Session replays don't appear in Amplitude

Session replays may not appear in Amplitude due to:

• Lack of connectivity
• The app process ends or you shut down the SDK before pending replay data uploads.
• Sampling

Lack of connectivity

Ensure your app has access to the internet then try again.

Sampling

As mentioned above, the default sampleRate for Session Replay is 0. Update the rate to a higher number. For more information see, Sampling rate.

Session Replay processing errors

In general, replays should be available within minutes of ingestion. Delays or errors may be the result of one or more of the following:

• Mismatching API keys or Device IDs. This can happen if Session Replay and standard event instrumentation use different API keys or Device IDs.
• Session Replay references the wrong project.
• Short sessions. If a users bounces within a few seconds of initialization, the SDK may not have time to upload replay data.
• Page instrumentation. If Session Replay isn't implemented on all pages a user visits, their session may not capture properly.
• Replays older than the set retention period (defaults to 90 days).

Report an Issue

If you encounter any issues with Session Replay that aren't covered in the troubleshooting guide above, please report them on our GitHub repository.

When creating an issue, please include:

• A clear description of the problem
• Steps to reproduce the issue
• Expected vs actual behavior
• SDK version you're using
• Any relevant error messages or logs

Captured sessions contain limited information

Amplitude automatically creates the [Amplitude] Replay Captured event when Session Replay captures a session. If you don't see this event in your implementation, replays may not appear correctly in Amplitude's analysis tools like Funnel Analysis, Segmentation, or Journeys charts. You can still find session replays on the Session Replay home page or the user profile page.

Reasons this event may not appear include:

• The user opted out or isn't part of the sample set given the current sampleRate. Increase the sampleRate to capture more sessions.
• You enabled the optOut configuration for the session. Check that optOut and sampleRate settings include the session.
• Your app uses a method other than the Android SDK to instrument events. Consider using the Session Replay Standalone SDK for Android.

If you verify these settings and still don't see the event, contact Amplitude support.

Replay length and session length don't match

In some scenarios, the length of a replay can exceed the time between the [Amplitude] Start Session and [Amplitude] End Session events. This situation happens when a user closes the app after the [Amplitude] End Session event occurs, but before the Android SDK and Session Replay plugin can process the event. When the user uses the app again, the SDK and plugin process the event and send it to Amplitude with the replay. To verify this scenario, check for a discrepancy between the End Session Client Event Time and the Client Upload Time.

Session replays don't appear in Amplitude

Session replays may not appear in Amplitude for these reasons:

• Lack of connectivity. Ensure your app has access to the internet, then try again.
• Failure to flush the recording before exiting the app.
• No events sent through the Android SDK in the current session.
• Missing [Amplitude] Replay Captured event. Review Captured sessions contain limited information.
• Sampling.

Sampling

The default sampleRate for Session Replay is 0. Update the rate to a higher number. For more information, refer to Sampling rate.

Session Replay processing errors

Replays should be available within minutes of ingestion. Delays or errors may result from one or more of the following:

• Mismatching API keys or Device IDs. This mismatch happens when Session Replay and standard event instrumentation use different API keys or Device IDs.
• Session Replay references the wrong project.
• Short sessions. If a user closes the app within a few seconds of initialization, the SDK may not have time to upload replay data.
• Page instrumentation. If you haven't implemented Session Replay on all pages a user visits, the session may not capture properly.
• Replays older than the set retention period (defaults to 90 days).