Configure Session Replay on crashes for Android

This page describes how to enable and customize Session Replay on crashes for your Android apps.

Session Replay on crashes visually recreates the last user actions before a crash occurred in your mobile application. It allows you to reproduce the issue that your users experienced so that you have the full context to understand what took place and why.

All technical information is available at JavaDoc for Dynatrace Session Replay.

Prerequisites

Make sure that your system meets the following requirements:

Dynatrace version 1.245+
OneAgent for Android version 8.245+

Real User Monitoring enabled for your application
Active Dynatrace Digital Experience Monitoring license
The web UI URL has a trusted certificate

Secondary disk configured to store user session data
To calculate the secondary disk size, consider the following:
- The size of a regular mobile user session is around 300 KB
- The default data retention period is 35 days
- Having some buffer is always good Using these estimates, we recommend that you calculate the secondary disk size using the following formula:
  Secondary disk size = Sessions ended with a crash per day * Average session size (300 KB) * Retention period (35 days) * Buffer (1.5)

Known limitations and issues

Technical limitations

Android 5.0+ (API level 21+) is supported.
Android Gradle plugin 7.0+ is supported.
Kotlin version 1.8+ is supported.
Jetpack Compose is not supported.
Only AndroidX support libraries are supported. Classes such as Activity or Fragment in com.android.support are not supported.

Session Replay is not available for Cordova, React Native, Flutter, or Xamarin.
For a hybrid app, Session Replay on crashes is supported only for the native part of the app. Session Replay is not supported for the browser part of a hybrid app.
We recommend that you not use other crash reporting tools together with Dynatrace Session Replay.
Session Replay can capture only certain events. However, if you need to track a specific view or event that is not supported by default, you can capture a custom event.
You can play back the user sessions recorded with Session Replay only in certain browsers.

See Technical restrictions for Session Replay for web applications for more information.

Known issues

Fragments with in-out animations can cause problems, especially when animations are short.
Floating action buttons can cause data masking issues.
The inputType attribute within the Button component might result in buttons appearing without text when captured.

Enable Session Replay on crashes

If you haven't done so already, complete all steps described in the instrumentation wizard.

Go to Mobile.
Select the mobile application that you want to configure.
Select More (…) > Edit in the upper-right corner of the tile with your application name.
From the application settings, select General > Enablement and cost control.
Turn on Enable Session Replay on crashes.
From the application settings, select General > Data privacy.
Turn on Enable user opt-in mode.
From the application settings, select Instrumentation wizard, and then select Android or iOS.
Follow the steps in the instrumentation wizard.

Mask sensitive data

Data masking levels

Session Replay on crashes comes with three predefined masking levels:

Safest—all the editable text fields, images, labels, web views, and switches are masked.
Safe—all the editable text fields are masked.
Custom—by default, masks the same elements as Safest, but you can decide exactly which application components or views should be masked. See Configure custom masking for details.

Change masking level

By default, OneAgent applies the Safest masking level. To change it to the Safe or Custom level, use the API to configure OneAgent. If you've opted for the Custom level, see Configure custom masking for details on how to set which application components or views should be masked.

Example 1: Change masking level to `Safe`

Use the following code to set the masking level to Safe.

MaskingConfiguration config = new MaskingConfiguration.Safe();  // .Safest or .Custom
DynatraceSessionReplay.setConfiguration(Configuration.builder()
      .withMaskingConfiguration(config)
      .build());

Example 2: Change masking level to `Custom`

Use the following code to set the masking level to Custom. For additional options, see Configure custom masking.

MaskingConfiguration config = new MaskingConfiguration.Custom();  // .Safest or .Safe
DynatraceSessionReplay.setConfiguration(Configuration.builder()
      .withMaskingConfiguration(config)
      .build());

Example 3: Change masking level to `Custom` and remove all masked views

Use the following code to set the masking level to Custom and remove all masked views (removeAllMaskedViews). For additional options, see Configure custom masking.

MaskingConfiguration config = new MaskingConfiguration.Custom().removeAllMaskedViews();
DynatraceSessionReplay.setConfiguration(Configuration.builder()
      .withMaskingConfiguration(config)
      .build());

Configure custom masking

If you set the data masking level to Custom, you can use additional API methods to decide which application components or views should be masked. You can:

Mask views.
Mask views using android:tag.
Mask views using a masking tag.

Mask views

You can enable or disable masking globally or for the selected components, such as text fields, images, labels, web views, and switches.

Set<Class<? extends View>> set = new HashSet<Class<? extends View>>()\{{
   add(ImageView.class);
   add(WebView.class);
}};
new MaskingConfiguration.Custom().addMaskedView(ImageView.class);    // Adds one masked view
new MaskingConfiguration.Custom().addMaskedViews(set);               // Adds all masked views
new MaskingConfiguration.Custom().removeMaskedView(ImageView.class); // Removes one masked view
new MaskingConfiguration.Custom().removeAllMaskedViews();            // Removes all masked views

You need to apply the custom masking configuration for it to take effect. See Change masking level to Custom and remove all masked views for the example code snippet.

Mask views using `android:tag`

You can also enable or disable masking of the selected views based on their android:tag.

Set<Integer> set = new HashSet<Integer>()\{{
   add(R.id.view_id1);
   add(R.id.view_id2);
}};
new MaskingConfiguration.Custom().addMaskedIds(set);
new MaskingConfiguration.Custom().addNonMaskedIds(set);
new MaskingConfiguration.Custom().removeMaskedIds(set);
new MaskingConfiguration.Custom().removeNonMaskedIds(set);

You need to apply the custom masking configuration for it to take effect. See Change masking level to Custom and remove all masked views for the example code snippet.

Mask views using a masking tag

You can also mask a view by adding the data-dtrum-mask masking tag to the view's android:tag. A view with this masking tag is always masked.

Enable Session Replay logs

You can enable Session Replay logs the same way as for OneAgent. See Enable debug logging for Dynatrace Android Gradle plugin or OneAgent SDK for more information.

Capture custom events

Session Replay records only certain events. However, you can track an event that is not supported by default.

DynatraceSessionReplay.trackCustomEvent("User logged")

Change transmission mode to Wi-Fi for images

By default, all data—information on captured events and images—is sent over any connection. However, you can opt to transfer images only when the users are connected to Wi-Fi to save their mobile data.

DynatraceSessionReplay.setConfiguration(
    Configuration.builder()
        .withDataTransmissionMode(DataTransmissionMode.NOT_METERED_NETWORK)
        .build()
)

Troubleshooting

Frequently asked questions

1.0 DEM unit per user session captured with Session Replay.

We've set hard limits of 300 KB per session and 10 MB for all sessions. Anything exceeding these limits gets trimmed down to the limits as mentioned above.

When recording a user session, Dynatrace may consume up to 10 MB of the user's mobile device storage. However, Dynatrace won't send a session that's more than 300 KB.

No. Session volume depends on a variety of factors, including the application size, session duration, and users' interactivity with the application.

No. To record sessions, Session Replay on crashes takes screenshots of the mobile app screen and its parts.

The data is sent one time. This is performed in several requests according to the data collected.

If you've changed the transmission mode to Wi-Fi, the images are sent only when the users of your app are connected to Wi-Fi.

Currently, there is no time limit for storing images; only the 10 MB hard limit mentioned above is applied. However, in emergency stop situations, everything is deleted.

Dynatrace sends the data immediately after the crash. The user does not have to relaunch the app.