For AI agents: a documentation index is available at /docs/llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.
세션 리플레이 Android 독립형 SDK
이 문서에서는 독립형 SDK를 사용하여 Android용 세션 리플레이를 설치하는 방법을 설명합니다. 제품 내 분석을 위해 Amplitude 이외의 공급자를 사용하는 경우, 이 옵션을 선택하십시오. 앱에서 이미 Amplitude Android SDK를 사용하고 있는 경우, 세션 리플레이 Android SDK 플러그인을 대신 사용하십시오.
문제 리포트
Android용 세션 리플레이와 관련된 문제를 리포트하려면 AmplitudeSessionReplay-Android GitHub 저장소로 이동하십시오.
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. Contact Amplitude if you experience issues with hierarchy processing.
시작하기 전에
세션 리플레이 독립형 SDK를 사용하려면 다음이 필요합니다.
- 사용자의 애플리케이션은 Android 기반입니다.
- 타임스탬프 또는 SDK에 전달할 수 있는 사용자 지정 문자열 세션 ID를 사용하여 세션을 추적합니다. 세션 식별자가 변경될 때마다 SDK에 알립니다.
- SDK에 장치 ID를 제공할 수 있습니다.
- 독립형 SDK에 전달하는
Session ID및Device ID는 Amplitude에 이벤트 속성으로 전송되는 항목과 일치합니다.
독립형 SDK는 세션 관리 기능을 제공하지 않습니다. 애플리케이션 또는 타사 연동 기능은 Session ID 및 Device ID에 대한 변경 사항을 적용하여 SDK를 업데이트해야 합니다.
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.
빠른 시작
최신 버전의 세션 리플레이 SDK를 프로젝트 종속성에 추가하십시오.
implementation("com.amplitude:session-replay-android:0.31.0")
애플리케이션 코드를 구성합니다.
- 리플레이 수집을 시작하려면
val sessionReplay = SessionReplay()객체를 생성합니다. API 키, 세션 식별자 및 장치 식별자를 전달합니다. - 세션 또는 기기 식별자가 변경되면
sessionReplay.setSessionId또는sessionReplay.setDeviceId를 사용하여 새 값을 Amplitude에 전달하십시오. 문자열 세션 ID의 경우sessionReplay.setCustomSessionId을 대신 사용하십시오. 사용자 지정 세션 ID를 참조하십시오. - 세션 리플레이 데이터를 Amplitude로 전송하려면
sessionReplay.flush를 호출하십시오. 앱이 종료되거나 백그라운드로 이동하기 전에 항상flush를 호출하십시오. 세션이 길어질 경우 메모리 사용량이 높아지지 않도록flush를 자주 호출하십시오(알파).
import com.amplitude.android.sessionreplay.SessionReplay
import com.example.ThirdPartyAnalytics
// Initialize the standalone session replay SDK
val sessionReplay = SessionReplay(
apiKey = "api-key",
context = applicationContext,
deviceId = "device-id",
sessionId = Date().time,
sampleRate = 1.0,
)
// Handle session ID change
// Whenever the session ID changes
ThirdPartyAnalytics.setSessionId(sessionId)
// Update the session ID in session replay
sessionReplay.setSessionId(ThirdPartyAnalytics.getSessionId())
// Handle device ID change
// When the device ID changes
ThirdPartyAnalytics.setDeviceId(deviceId)
//Update the device ID in session replay
sessionReplay.setDeviceId(ThirdPartyAnalytics.getDeviceId())
// Send session replay data to the server
// This should always be called before app exit
sessionReplay.flush()
구성
세션 리플레이 SDK를 초기화할 때 다음 구성 옵션을 전달하십시오.
| 옵션 | 유형 | 필수 | 기본값 | 설명 |
|---|---|---|---|---|
apiKey | String | 예 | 해당 없음 | 사용자의 Amplitude API 키. |
context | Context | 예 | 해당 없음 | Android 애플리케이션 컨텍스트입니다. |
deviceId | String | 예 | 해당 없음 | 애플리케이션을 실행하는 장치의 식별자입니다. |
sessionId | Long | 예 | 해당 없음 | 에포크 날짜 이후 밀리초 단위(Unix 타임스탬프)의 사용자 현재 세션 식별자입니다. 대신 문자열 세션 ID를 사용하려면 -1을 전달하고 초기화 후 setCustomSessionId를 호출하십시오. 사용자 지정 세션 ID를 참조하십시오. |
sampleRate | Number | 아니요 | 0.0 | Amplitude가 재생 수집을 위해 선택하는 세션 수를 제어합니다. 예를 들어 0.4처럼 0과 1 사이의 소수를 사용하면 많은 수의 세션에 대해 40%의 세션을 선택하게 됩니다. |
optOut | Boolean | 아니요 | false | 재생을 수집할 수 있는 권한을 설정합니다. 값이 true 이면 Amplitude가 세션 리플레이를 수집하지 못하게 됩니다. |
logger | Logger | 아니요 | LogcatLogger | 로그 메시지를 목적지로 내보내도록 사용자 지정 로거를 설정합니다. 로깅을 비활성화하려면 null로 설정하십시오. |
enableRemoteConfig | Boolean | 아니요 | true | 이 세션 리플레이 인스턴스에 대한 원격 구성을 활성화하거나 비활성화합니다. |
serverZone | ServerZone | 아니요 | ServerZone.US | ServerZone.EU 또는 ServerZone.US. EU 데이터 센터에서 생성된 Amplitude 프로젝트의 경우 이 값을 EU로 설정하십시오. |
privacyConfig | PrivacyConfig | 아니요 | PrivacyConfig() | 마스크되는 뷰를 제어하는 개인정보 보호 설정입니다. PrivacyConfig(maskLevel = MaskLevel.MEDIUM)를 사용하여 마스크 수준을 설정합니다. 마스크 수준을 참조하십시오. |
serverUrl | String? | 아니요 | null | 고급옵션. 명시적 서버 URL로, 프록시 설정에 유용합니다. |
bandwidthLimitBytes | Int? | 아니요 | null | 고급옵션. 종량제(예: 셀룰러) 연결에서의 바이트 단위 일일 업로드 제한입니다. |
storageLimitMB | Int? | 아니요 | null | 고급옵션. 로컬 스토리지 제한(MB)입니다. |
autoStart | Boolean | 아니요 | true | 세션 리플레이가 초기화될 때 자동으로 화면 캡처를 시작합니다. |
recordLogOptions.logCountThreshold | Int | 아니요 | 1000 | 세션당 최대 로그 수입니다. |
recordLogOptions.maxMessageLength | Int | 아니요 | 2000 | 로그 메시지의 최대 길이입니다. |
사용자 지정 세션 ID
Android 버전 0.26.4 이상용 세션 리플레이는 setCustomSessionId 메서드를 통해 문자열 세션 ID(예: UUID)를 지원합니다. 프로젝트에서 타임스탬프 기반 session_id 대신 사용자 지정 이벤트 속성을 사용하여 세션을 정의하는 경우 사용자 지정 세션 ID를 사용하십시오.
생성자는 숫자 sessionId만 허용합니다. 문자열 값을 사용하려면 -1를 sessionId(으)로 전달한 다음 setCustomSessionId를 호출하십시오. 유효한 세션 ID를 설정할 때까지 세션 리플레이는 캡처되지 않습니다.
val sessionReplay = SessionReplay(
apiKey = API_KEY,
context = applicationContext,
deviceId = "device-id",
sessionId = -1,
sampleRate = 1.0,
)
// Set a string session ID instead of the numeric sessionId
sessionReplay.setCustomSessionId("ef197fc7-a46f-4e6c-a77f-8d90c17065c0")
// Whenever your custom session changes
sessionReplay.setCustomSessionId(ThirdPartyAnalytics.getCustomSessionId())
숫자 sessionId와 사용자 지정 세션 ID는 동일한 기본 값에 대한 두 가지 뷰이며, SDK는 이를 문자열로 저장합니다.
setSessionId를 호출하면 현재 사용자 지정 세션 ID가 숫자 값으로 바뀝니다. 사용자 지정 세션 ID를 사용할 경우 세션이 변경될 때마다setCustomSessionId를setSessionId대신 호출하십시오.- 저장된 값이 숫자가 아닐 경우
getSessionId는-1를 반환합니다. 현재 값을 읽으려면getCustomSessionId를 호출하십시오. - 다른 값을 설정하면 현재 재생이 종료되고 새 재생이 시작됩니다.
세션 리플레이가 사용자 정의 세션을 안정적으로 일치시키려면 사용자 정의 세션 ID가 다음 제약 조건을 따라야 합니다.
- 이 값은
/을 포함할 수 없습니다. 세션 리플레이는/을 세션 리플레이 ID의 구분 기호로 사용하며, 형식은<deviceId>/<sessionId>입니다. - 값에는
a-z A-Z 0-9 _ - . | @ : =문자만 포함할 수 있습니다. - 이 값은 이벤트에 대해 Amplitude로 전송하는 세션 정의 속성과 일치해야 합니다. 자세한 내용은 세션 일치를 참조하십시오.
Remote configuration
Enable remote configuration to set Sample Rate and Masking Level in Amplitude.
Remote configuration and testing
With enableRemoteConfig set to true, settings you define in Amplitude take precedence over settings you define locally in the SDK. For this reason, while testing your application, you should disable remote configuration to ensure you can set sampleRate to 1, and ensure you capture test sessions.
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.
| Mask level | Description |
|---|---|
light | Masks password, email, and phone number input fields. In SDK 0.26.2 and later, light also masks any field with sensitive autofill hints (credit card number, expiration, and security code; name; username; postal address and code); autofill-hint detection requires Android 8.0 (API 26) or higher. Earlier versions, including the middleware-session-replay-android artifact, mask only the input-field types above. |
medium (default) | Everything in light, plus all editable text fields (EditText). |
conservative | Everything in medium, plus all text views (TextView). |
Privacy tags in layout XML
Use this option in your application's layout XML.
| 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. |
<WebView> | To unmask a web view, add the amp-unmask tag. For example, <WebView android:tag="amp-unmask"/>. |
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
| Method | Description |
|---|---|
unmask(view: View) | To unmask a view manually, call SessionReplay.unmask(view) where view is a reference to any view that is masked. |
mask(view: View) | To mask text within non-input views, call SessionReplay.mask(view) where view is a reference to the any view 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.block(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 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
| Modifier | Description |
|---|---|
Modifier.ampMask() | Masks text that Session Replay captures by default, such as the contents of a Text composable. Session Replay captures masked text as a series of asterisks. |
Modifier.ampUnmask() | Unmasks a composable that Session Replay masks by default, such as a TextField. |
Modifier.ampBlock() | Blocks a composable. Session Replay replaces blocked composables with a placeholder of the same dimensions and doesn't capture their contents. |
// 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.
사용자 옵트아웃
세션 리플레이는 옵트아웃 구성 옵션을 제공합니다. Amplitude가 세션 리플레이를 수집하지 못하도록 초기화 중에 optOut = true을(를) 전달하세요. 예를 들면 다음과 같습니다.
// Pass a boolean value to indicate a users opt-out status
val sessionReplay = SessionReplay(
apiKey = API_KEY,
optOut = true,
/* other session replay options */
)
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 to EU
val sessionReplay = SessionReplay(
apiKey = API_KEY,
serverZone = ServerZone.EU,
/* other session replay options */
)
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. - Replays with processing errors don't count toward your monthly quota. Replays with a retention error message have already been counted against the quota, when the session was still in the retention period.
// This configuration samples 1% of all sessions
val sessionReplay = SessionReplay(
apiKey = API_KEY,
sampleRate = 0.01,
/* other session replay options */
)
리플레이 수집 비활성화
세션 리플레이가 시작된 후 다음 중 하나가 발생할 때까지 앱에서 실행됩니다:
- 사용자가 앱을 떠납니다.
sessionReplay.stop()을(를) 호출하십시오.- 인스턴스를 제거하기 위해
sessionReplay.shutdown()를 호출합니다.
사용자가 앱의 제한된 영역에 있는 동안 리플레이 수집을 일시 중지하려면, 해당 영역으로 이동하기 전에 sessionReplay.stop()를 호출하십시오. 돌아오면 sessionReplay.start()에 전화하여 재개하십시오. 두 메서드는 동일한 인스턴스에서 작동합니다.
세션 리플레이를 완전히 해제하려면 sessionReplay.shutdown()를 호출한 다음 새 인스턴스를 생성하여 다시 시작하십시오.
특정 화면만 캡처하려면 앱 실행 시 자동으로 시작되지 않도록 autoStart = false를 사용하여 세션 리플레이를 초기화한 다음, 사용자가 해당 화면에 들어오거나 나갈 때 start() 및 stop()를 호출하십시오.
val sessionReplay = SessionReplay(
apiKey = API_KEY,
context = applicationContext,
deviceId = "device-id",
sessionId = Date().time,
autoStart = false,
)
// Start capture when the user enters a screen you want to record
sessionReplay.start()
// Stop capture when the user leaves that screen
sessionReplay.stop()
또한 Amplitude 실험과 같은 기능 플래그 제품을 사용하여 위치와 같은 기준에 따라 리플레이 수집을 활성화하거나 비활성화하는 로직을 만들 수도 있습니다. 예를 들어, 특정 사용자 그룹을 대상으로 하는 기능 플래그를 생성한 다음 해당 플래그를 초기화 논리에 추가합니다.
import com.amplitude.android.sessionreplay.SessionReplay
import com.example.ThirdPartyAnalytics
val sessionReplay = SessionReplay(
apiKey = API_KEY,
deviceId = "device-id",
sessionId = Date().time,
sampleRate = 1.0,
/* other session replay options */
)
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
Availability
Log recording is available in Session Replay Android 0.22.0 and later.
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
Session replay uses existing Amplitude tools and APIs to handle privacy and deletion requests. <!--vale off-->
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.
Retention periods are set at the organization level. 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.
{
"amplitude_id": 123456789,
"app": 12345,
"event_time": "2020-02-15 01:00:00.123456",
"event_type": "first_event",
"server_upload_time": "2020-02-18 01:00:00.234567",
"device_id": "your device id",
"user_properties": { ... }
"event_properties": {
"[Amplitude] Session Replay ID": "cb6ade06-cbdf-4e0c-8156-32c2863379d6/1699922971244"
}
"session_id": 1699922971244,
}
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 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.
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
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
이 내용이 도움이 되었나요?