Set Up Session Replay

Learn how to enable the Beta of Mobile Session Replay in your app.

Mobile support for Session Replay is in Beta. Features available in Beta are still work-in-progress and may have bugs. We recognize the irony.

If you have any questions, feedback or would like to report a bug, please open a GitHub issue with a link to a relevant replay in Sentry if possible.

Session Replay helps you get to the root cause of an error or latency issue faster by providing you with a reproduction of what was happening in the user's device before, during, and after the issue. You can rewind and replay your application's state and see key user interactions, like taps, swipes, network requests, and console entries, in a single UI.

By default, our Session Replay SDK masks all text content, images, and user input, giving you heightened confidence that no sensitive data will leave the device. To learn more, see product docs.

Make sure your Sentry Android SDK version is at least 7.12.0.

The easiest way to update through the Sentry Android Gradle plugin to your app module's build.gradle file.

app/build.gradle
Copied
plugins {
  id "com.android.application"
  id "io.sentry.android.gradle" version "4.13.0"
}

If you have the SDK installed without the Sentry Gradle Plugin, you can update the version directly in the build.gradle through:

app/build.gradle
Copied
dependencies {
    implementation 'io.sentry:sentry-android:7.16.0'
}

To set up the integration, add the following to your Sentry initialization.

Copied
SentryAndroid.init(context) { options ->
  options.dsn = "https://examplePublicKey@o0.ingest.sentry.io/0"
  options.isDebug = true

  // Currently under experimental options:
  options.experimental.sessionReplay.onErrorSampleRate = 1.0
  options.experimental.sessionReplay.sessionSampleRate = 1.0
}

While you're testing, we recommend that you set sessionSampleRate to 1.0. This ensures that every user session will be sent to Sentry.

Once testing is complete, we recommend lowering this value in production. We still recommend keeping onErrorSampleRate set to 1.0.

Sampling allows you to control how much of your website's traffic will result in a Session Replay. There are two sample rates you can adjust to get the replays relevant to you:

  1. sessionSampleRate - The sample rate for replays that begin recording immediately and last the entirety of the user's session.
  2. onErrorSampleRate - The sample rate for replays that are recorded when an error happens. This type of replay will record up to a minute of events prior to the error and continue recording until the session ends.

Sampling begins as soon as a session starts. sessionSampleRate is evaluated first. If it's sampled, the replay recording will begin. Otherwise, onErrorSampleRate is evaluated and if it's sampled, the integration will begin buffering the replay and will only upload it to Sentry if an error occurs. The remainder of the replay will behave similarly to a whole-session replay.

The SDK is recording and aggressively masking all text, images and webviews. Please don’t turn it off if you have sensitive data in your app. However, if you're working on a mobile app that's free of PII or other types of private data, you can opt out of the default text and image masking settings. To learn more about Session Replay privacy, read our docs.

If you find that any other data isn't being masked with the default settings, please let us know by creating a GitHub issue.

To disable masking altogether (not to be used on applications with sensitive data):

Copied
options.experimental.sessionReplay.maskAllText = false
options.experimental.sessionReplay.maskAllImages = false
// if you're on version < 7.15.0
// options.experimental.sessionReplay.redactAllText = false
// options.experimental.sessionReplay.redactAllImages = false

Errors that happen while a replay is running will be linked to the replay, making it possible to jump between related issues and replays. However, it's possible that in some cases the error count reported on the Replays Details page won't match the actual errors that have been captured. That's because errors can be lost, and while this is uncommon, there are a few reasons why it could happen:

  • The replay was rate-limited and couldn't be accepted.
  • The replay was deleted by a member of your org.
  • There were network errors and the replay wasn't saved.

Q: Why are parts of my replay not masked? A: Text fields, input fields, images, video players and webviews are all masked by default. Local assets, such as colors or vector drawables, aren't masked because the likelihood of these assets containing PII is low. If you encounter a view/component that should be masked by default, consider opening a GitHub issue.

Q: Does Session Replay work with Jetpack Compose? A: Yes, by default, text, input field, and image composables should be masked. Masking within embedded Android views (AndroidView) in Compose isn't currently supported. If you encounter composables that aren't masked but should be, consider opening a GitHub issue.

Q: What's the lowest version of Android supported? A: Recording only happens on Android 8 (API level 26) or newer. For devices running an older version, SDK features other than recording work normally.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").