Session Replay Android Standalone SDK

Early access SDK

As an Alpha release, this SDK may contain bugs and cause crashes. Before you enable in production, thoroughly test your app in a controlled environment. For more information about best practices for developer preview SDKs, see SDK Maintenance and Support.

This article covers the installation of Session Replay for Android using the standalone SDK. If you use a provider other than Amplitude for in-product analytics, choose this option. If your app is already instrumented with Amplitude Android SDK, use the Session Replay Android SDK Plugin.

Session Replay and performance

Amplitude built Session Replay to minimize impact on the performance of the Android apps in which it's installed by:

  • Asynchronously capturing and processing replay data, to avoid blocking the main user interface thread. The main thread must analyze the view hierarchy, but snapshot capture scheduling and extra processing offloads to the background.
  • Using batching and lightweight compression to reduce the number of network connections and bandwidth.
  • Optimizing view hierarchy processing. This is a work in progress. Contact Amplitude if you experience issues with hierarchy processing.

Before you begin

Use the latest version of the Session Replay SDK above version 0.6.5. For a list of available versions, see the release versions on Maven Central.

Session Replay Standalone SDK requires that:

  1. Your application is Android-based.
  2. You track sessions with a timestamp, which you can pass to the SDK. You inform the SDK whenever a session timestamp changes.
  3. You can provide a device ID to the SDK.
  4. The Session ID and Device ID you pass to the Standalone SDK must match those sent as event properties to Amplitude.

The Standalone SDK doesn't provide Session management capabilities. Your application or a third-party integration must update the SDK with changes to Session ID and Device ID.

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

Add the latest version Session Replay SDK to your project dependencies.

1implementation("com.amplitude:session-replay-android:@{$ android.session_replay.version $}")

Configure your application code.

  1. Create a val sessionReplay = SessionReplay() object to begin collecting replays. Pass the API key, session identifier, and device identifier.
  2. When the session identifier changes, pass the new value to Amplitude with sessionReplay.setSessionId.
  3. Collect Session Replay properties to send with other event properties with sessionReplay.getSessionReplayProperties
  4. Call sessionReplay.flush to send session replay data to Amplitude. Always call flush before exiting the app or sending it to the background. For longer sessions, call flush often to prevent high memory use (alpha).
1import com.amplitude.android.sessionreplay.SessionReplay
2import com.example.ThirdPartyAnalytics
3 
4// Initialize the standalone session replay SDK
5val sessionReplay = SessionReplay(
6 apiKey = "api-key",
7 context = applicationContext,
8 deviceId = "device-id",
9 sessionId = Date().time,
10 sampleRate = 1.0,
11)
12 
13// Track an event
14// Get session replay properties for this session
15val sessionReplayProperties = sessionReplay.getSessionReplayProperties()
16// Add session replay properties to the event before tracking
17ThirdPartyAnalytics.track(
18 eventName,
19 if (eventProperties == null) sessionReplayProperties else eventProperties + sessionReplayProperties
20)
21 
22// Handle session ID change
23// Whenever the session ID changes
24ThirdPartyAnalytics.setSessionId(sessionId)
25// Update the session ID in session replay
26sessionReplay.setSessionId(ThirdPartyAnalytics.getSessionId())
27 
28// Send session replay data to the server
29// This should always be called before app exit
30sessionReplay.flush()

Jetpack Compose

Capturing @Composable Compose views requires extra setup.

Add the Compose UI Tooling library to your project.

1implementation("androidx.compose.ui:ui-tooling:${composeVersion}")

Session Replay for Android supports Jetpack Compose 1.5.x and 1.6.x. It's tested on [1.5.3,1.6.4].

Configuration

Pass the following configuration options when you initialize the Session Replay SDK.

Name Type Required Default Description
deviceId String Yes null Sets an identifier for the device running your application.
sessionId Long Yes null Sets an identifier for the users current session. The value must be in milliseconds since epoch (Unix Timestamp).
sampleRate Number No 0.0 Use this option to control how many sessions to select for replay collection.

The number should be a decimal between 0 and 1, for example 0.4, representing the fraction of sessions to have randomly selected for replay collection. Over a large number of sessions, 0.4 would select 40% of those sessions.
optOut Boolean No false Sets permission to collect replays for sessions. Setting a value of true prevents Amplitude from collecting session replays.
logger Logger No LogcatLogger Sets a custom logger class from the Logger to emit log messages to desired destination. Set to null to disable logging.
serverZone ServerZone No ServerZone.US ServerZone.EU or ServerZone.US. Sets the Amplitude server zone. Set this to EU for Amplitude projects created in EU data center.

Mask on-screen data

By default session replay hides all user input (EditText, inputType="password")

The Session Replay SDK offers three ways to mask user input, text, and other View components. This can be enabled in both the layout XML and Kotlin/Java code.

Privacy tags in layout XML

Privacy control

View Description
<EditText> Session Replay masks all text input fields by default. When a users enters text into an input field, Session Replay captures asterisks in place of text. To unmask a text input, add the tag amp-unmask. For example: <EditText android:tag="amp-unmask" android:text="Unmask this">.
<TextView> To mask text within non-input elements, add the tag amp-mask. For example, <TextView android:tag="amp-mask" android:text="Mask this"/>. When masked, Session Replay captures masked text as a series of asterisks.
non-text elements To block a non-text element, add the tag amp-block. For example, <ImageView android:tag="amp-block"/>. Session Replay replaces blocked elements with a placeholder of the same dimensions.

Privacy methods on the Session Replay SDK

To use privacy methods first import the SessionReplay class. Then call one of the methods below.

1import com.amplitude.android.SessionReplay
Method Description
unmask(view: View) Session Replay masks all text input views by default. When a user enters text into an input view, Session Replay captures asterisks in place of text. To unmask a text input, call SessionReplay.unmask(view) where view is a reference to the text input you want to unmask.
mask(view: View) To mask text within non-input views, call SessionReplay.mask(view) where view is a reference to the text input you want to mask. When masked, Session Replay captures masked text as a series of asterisks.
block(view: View) To block a non-text view, call SessionReplay.unmask(view) where view is a reference to the View you want to block. Session Replay replaces blocked views with a placeholder of the same dimensions.

Privacy Modifiers for Jetpack Compose

Three privacy Modifiers are included. Modifier.ampUnmask().ampMask().ampBlock(). When combined the most private modifier wins.

Method Description
ampUnmask() Session Replay masks all text input views by default. When a user enters text into an input view, Session Replay captures asterisks in place of text. To unmask a text input, add Modifier.ampUnmask() to the Composable you want to unmask.
ampMask() To mask text within non-input views, call Modifier.ampMask() to the Composable you want to mask. When masked, Session Replay captures masked text as a series of asterisks.
ampBlock() To block a non-text view, call Modifier.ampBlock() to the Composable you want to block. Session Replay replaces blocked views with a placeholder of the same dimensions.

User opt-out

Session Replay provides an option for opt-out configuration. This prevents Amplitude from collecting session replays when passed as part of initialization. For example:

1// Pass a boolean value to indicate a users opt-out status
2val sessionReplay = SessionReplay(
3 apiKey = API_KEY,
4 optOpt = true,
5 /* other session replay options */
6)

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:

1// Set serverZone to EU
2val sessionReplay = SessionReplay(
3 apiKey = API_KEY,
4 serverZone = ServerZone.EU,
5 /* other session replay options */
6)

Sampling rate

By default, Session Replay captures 0% of sessions for replay. Use the sampleRate configuration option to set the percentage of total sessions that Session Replay captures. For example:

To set the sampleRate consider the monthly quota on your Session Replay plan. For example, if your monthly quota is 2,500,000 sessions, and you average 3,000,000 monthly sessions, your quota is 83% of your average sessions. In this case, to ensure sampling lasts through the month, set sampleRate to .83 or lower.

Keep the following in mind as you consider your sample rate:

  • When you reach your monthly session quota, Amplitude stops capturing sessions for replay.
  • Session quotas reset on the first of every month.
  • Use sample rate to distribute your session quota over the course of a month, rather than using your full quota at the beginning of the month.
  • To find the best sample rate, Amplitude recommends that you start low, for example .01. If this value doesn't capture enough replays, raise the rate over the course of a few days. For ways to monitor the number of session replays captured, see View the number of captured sessions.

1// This configuration samples 1% of all sessions
2val sessionReplay = SessionReplay(
3 apiKey = API_KEY,
4 sampleRate = 0.01,
5 /* other session replay options */
6)

Disable replay collection

Once enabled, Session Replay runs on your app until either:

  • The user leaves your app
  • You call sessionReplay.shutdown()

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

Create a new instance sessionReplay = SessionReplay(apiKey = API_KEY, /* options */) to re-enable replay collection when the return to an unrestricted area of your app.

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

1import com.amplitude.android.sessionreplay.SessionReplay
2import com.example.ThirdPartyAnalytics
3 
4val sessionReplay = SessionReplay(
5 apiKey = API_KEY,
6 deviceId = "device-id",
7 sessionId = Date().time,
8 sampleRate = 1.0,
9 /* other session replay options */
10)
11 
12if (nonEUCountryFlagEnabled) {
13 val sessionReplayProperties = sessionReplay.getSessionReplayProperties()
14 ThirdPartyAnalytics.track(
15 eventName = 'event',
16 eventProperties = eventProperties + sessionReplayProperties
17 )
18}

Bitmap Capture

Bitmap capture is disabled by default

Enabling bitmap capture may increase the amount of CPU and memory used by the Session Replay SDK. This performance will be improved in future releases.

To enable bitmap capture, use one or more of the following

  1. Set internalOptions.bitmapViewFilter=ViewFilter(). For example, SessionReplay(internalOptions=InternalOptions(bitmapViewFilter = ViewFilters.ImageViewFilter())) will capture all ImageView views and Role.Image elements in Compose. You can define your own capture rules by extending the ViewFilter interface and using matches(mobileNode, view) to filter what views to capture as bitmaps.
  2. In Android XML, add android:tag="amp-bitmap"" to your view. For example, <View android:tag="amp-bitmap"></View>
  3. In Compose layouts, add a Modifier.ampBitmap() to the view modifiers. For example, Checkbox(checked = true, modifier = Modifier.ampBitmap())

Data retention, deletion, and privacy

Session replay uses existing Amplitude tools and APIs to handle privacy and deletion requests.

Consent management and Session Replay

While privacy laws and regulations vary across states and countries, certain constants exist, including the requirements to disclose in a privacy notice the categories of personal information you are collecting, the purposes for its use, and the categories of third parties with which personal information is shared. When implementing a session replay tool, you should review your privacy notice to make sure your disclosures remain accurate and complete. And as a best practice, review your notice with legal counsel to make sure it complies with the constantly evolving privacy laws and requirements applicable to your business and personal information data practices.

Retention period

If your Amplitude plan includes Session Replay, Amplitude retains raw replay data for 30 days from the date of ingestion.

If you purchase extra session volume, Amplitude retains raw replay data for 90 days from the date of ingestion. If you need a more strict policy, contact Amplitude support to set the value to 30 days.

Changes to the retention period impact replays ingested after the change. Sessions captured and ingested before a retention period change retain the previous retention period.

Replays that are outside of the retention period aren't viewable in Amplitude.

DSAR API

The Amplitude DSAR API returns metadata about session replays, but not the raw replay data. All events that are part of a session replay include a [Amplitude] Session Replay ID event property. This event provides information about the sessions collected for replay for the user, and includes all metadata collected with each event.

1{
2 "amplitude_id": 123456789,
3 "app": 12345,
4 "event_time": "2020-02-15 01:00:00.123456",
5 "event_type": "first_event",
6 "server_upload_time": "2020-02-18 01:00:00.234567",
7 "device_id": "your device id",
8 "user_properties": { ... }
9 "event_properties": {
10 "[Amplitude] Session Replay ID": "cb6ade06-cbdf-4e0c-8156-32c2863379d6/1699922971244"
11 }
12 "session_id": 1699922971244,
13}

Data deletion

Session Replay uses Amplitude's User Privacy API to handle deletion requests. Successful deletion requests remove all session replays for the specified user.

When you delete the Amplitude project on which you use Session Replay, Amplitude deletes that replay data.

Bot filter

Session Replay uses the same block filter available in the Amplitude app. Session Replay doesn't block traffic based on event or user properties.

Session Replay storage

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

(alpha) Session Replay stores data in memory only.

  • This can lead to data loss between app starts. Make sure to call flush() before app exit.
  • Memory usage grows until you call flush() to transfer the session replay data to the server.
  • Session data isn't retried on failure to transfer to the Amplitude servers.

Known limitations

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

  • (alpha) Session replay stores data in memory only. This can lead to data loss between app starts. Learn more in Session Replay storage.

  • (alpha)Session replay doesn't support all view components. Contact Amplitude (with a session replay link) for more information.

  • 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:

    • ImageView
    • WebView
    • Static assets like fonts, drawable, and images from the res folder.

Troubleshooting

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

Styles, fonts, drawables, images don't appear in replay

(alpha) When Amplitude captures a replay, it doesn't transfer or store styles or other static assets that are part of your application.

Session Replay doesn't support the following in this version:

  • Images
  • Drawables
  • Fonts
  • Custom styles

View components don't appear in replay

(alpha) Session replay is in alpha and doesn't support all Android View components.

View Feature Support Level Notes
Layout: position Full
Layout: dimensions Full
Layout: padding Partial Broken for some text views
Layout: insets Partial Buttons are supported
View: background color Full
View: background drawable In progress
View: background radius Full
View: scrolling Partial
View: animations Partial Any animations adding/removing views are supported.
Images: placeholders Full
Images: bitmaps In progress
Text: alignment Partial
Text: size Partial
Text: color Full
Text: font In progress
Text: fontFamily Full
Text: all caps None Issue in Android SDK. isAllCaps doesn't work.
Text: compound drawables Partial Left/right drawables added to text views have placeholders. Top/bottom drawables aren't supported
Touch: up Full
Touch: down Full
Touch: move In progress
WebView In progress
MapView In progress
Canvas Views In progress Views that draw to a custom Canvas aren't supported.

Session replays don't appear in Amplitude

Session replays may not appear in Amplitude due to:

  • Lack of connectivity
  • Failed to flush recording before exiting the app
  • Sampling

Lack of connectivity

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

Failed to flush recording before exiting the app

Session replay stores data in memory only. This can lead to data loss between app starts.

Make sure to call sessionReplay.flush() to flush all pending session replay data before app exit.

Learn more in Session Replay storage.

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.

Some sessions don't include the Session Replay ID property

Session replay doesn't require that all events in a session have the [Amplitude] Session Replay ID property, only that one event in the session has it. Reasons why [Amplitude] Session Replay ID may not be present in an event include:

  • The user may have opted out or may not be part of the sample set given the current sampleRate. Increasing the sampleRate captures more sessions.
  • Amplitude events may still send through your provider, but getSessionReplayProperties() doesn't return the [Amplitude] Session Replay ID property. This can result from optOut and sampleRate configuration settings. Check that optOut and sampleRate are set to include the session.

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).
Was this page helpful?

Thanks for your feedback!

June 25th, 2024

Need help? Contact Support

Visit Amplitude.com

Have a look at the Amplitude Blog

Learn more at Amplitude Academy

© 2024 Amplitude, Inc. All rights reserved. Amplitude is a registered trademark of Amplitude, Inc.