> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SDK developer compliance guide
> The Flashduty RUM SDK's personal information processing rules, permissions, and data handling commitments, plus the privacy disclosure and deferred-initialization obligations for integrators
This guide explains how the Flashduty RUM SDK (the "SDK") processes personal information within your app, and helps you meet China's Personal Information Protection Law (PIPL), the relevant app personal-information collection regulations, and the privacy requirements of various app stores. It focuses on the SDK's own processing rules; Flashduty's service terms and data security commitments as the entrusted processor are covered separately in the [Data protection agreement](/en/compliance/data-security) and the RUM [Data security](/en/rum/others/data-security) doc.
## Two key requirements for compliant use
After integrating the SDK, you (the app operator) must complete the following **two** compliance actions — both are mandatory:
Disclose in your app's privacy policy that the SDK is integrated and what personal information it collects. See [Privacy policy disclosure](#1-privacy-policy-disclosure).
Do not initialize the SDK or report any data **before** the user accepts your privacy policy. See [Deferred initialization](#2-deferred-initialization).
Going live without completing these actions may cause your app to be flagged for "illegal collection and use of personal information" during app-store review or regulatory privacy-compliance scans. The rest of this guide explains the factual basis behind these two requirements and the concrete steps to implement them.
## Division of compliance responsibilities
The SDK runs as a third-party component embedded in your app. The responsibility boundary is as follows:
| Role | Party | Responsibility |
| ------------------------------ | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Personal information processor | **You (the app operator)** | Disclose and obtain consent for your app's overall collection and use of personal information, including the integrated SDK |
| Entrusted processor | **Beijing Flashcat Cloud Technology Co.,Ltd. (Flashduty)** | Process data only within the scope necessary to provide RUM services, never for purposes beyond what is agreed |
Under Article 21 of China's Personal Information Protection Law, you and Flashduty form an entrusted-processing relationship: you determine the purpose, means, and categories of personal information processed, while Flashduty only processes data as agreed, takes the necessary measures to safeguard it, does not use it beyond the agreed scope, and does not sub-entrust the processing. The rights and obligations of both parties are governed by the [Data protection agreement](/en/compliance/data-security).
## How the SDK processes personal information
The following is the factual basis for completing your privacy policy disclosure.
### Personal information collected
Following the principle of data minimization, the SDK collects only information directly related to implementing crash analysis, performance diagnostics, and user experience monitoring, and does not collect personal information unrelated to these functions. The table below itemizes the information types, fields, purposes, and collection methods. Apart from "app runtime information", all collection items can be disabled or masked via configuration (see [Data handling rules and commitments](#data-handling-rules-and-commitments)).
| Information type | Specific fields | Purpose | Collection method | Can be disabled |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------ | ----------------------------------- |
| Device information | Device model, brand, device name, CPU architecture, screen information | Distinguish crashes and performance across device models | Collected automatically by the SDK | No (base attribute) |
| Operating system information | OS name and version | Distinguish compatibility and fault distribution across OS versions | Collected automatically by the SDK | No (base attribute) |
| Network information | Connectivity status, network interface type (Wi-Fi / cellular / wired network, etc.), uplink/downlink bandwidth, signal strength | Analyze how the network affects loading and request latency | Collected automatically by the SDK | No (base attribute) |
| App runtime information | Package name, version, build number, environment, SDK version | Correlate issues with releases | Collected automatically by the SDK | No (required) |
| Crash and log information | Crash stack traces, error messages, ANR, custom logs | Reconstruct the crash scene and locate defects | Collected on crash/error or manual logging | Yes (disable error tracking) |
| Behavior and performance information | View access paths and dwell time, user actions, resource loading latency, long tasks, launch time | Reconstruct user journeys and analyze bottlenecks | Collected on interaction/navigation | Yes (disable auto tracking or mask) |
| Session identifier | Randomly generated session ID (`session.id`) | Link events within a single session for traceability | Generated automatically by the SDK | No (already anonymized) |
| Network address | Country/region derived from the report's source IP | Analyze performance and faults by region | Derived server-side during processing | Yes (disable IP / geolocation) |
### Information explicitly not collected
To minimize privacy impact, the SDK does **not** collect the following, and does **not** request the related sensitive permissions:
* Unique device identifiers: **IMEI, IDFA, IDFV, Android ID, MAC address, OAID**, etc.
* Precise geolocation (GPS / latitude-longitude).
* Contacts, SMS, call logs, photo albums, microphone, or camera content.
* The list of installed apps.
* SIM carrier name / carrier ID (`simCarrierIdName` / `simCarrierId`), and telephony identifiers such as IMSI or SIM serial number.
* Directly identifiable information such as phone numbers or ID numbers (unless you actively pass it in via the API — see the note below).
The SDK commits not to collect the above information through covert, misleading, or deceptive means, and does not read or transmit device data unrelated to monitoring.
If you actively pass personally identifiable information to the SDK via `setUserInfo` (user ID, name, email) or custom attributes, this information is reported along with events. Make sure such collection is disclosed in your privacy policy and consented to, and **avoid passing in sensitive personal information**.
### Device permissions requested
Following the principle of least privilege, the SDK only requests the network permissions necessary for monitoring. It does not request sensitive permissions such as location, camera, microphone, contacts, phone, or storage, and does not present runtime sensitive-permission prompts to the user.
| Platform | Permission | Purpose | Required |
| -------- | --------------------------------------------- | ----------------------------------------------------------------- | -------- |
| Android | `android.permission.INTERNET` | Report monitoring data | Required |
| Android | `android.permission.ACCESS_NETWORK_STATE` | Read network status for metrics collection and reporting strategy | Required |
| iOS | No additional permission declaration required | Network access uses the system default capability | — |
### Data handling rules and commitments
Beyond collecting data on a minimal, as-needed basis, the SDK provides the following data-handling mechanisms and commitments to help you further control the collection scope and reduce privacy risk:
The SDK collects only the information necessary for monitoring. Sessions are identified by a random `session.id` and user identity is not tracked by default, anonymizing the data while preserving trend analysis.
You can finely control collection behavior:
* **Disable auto tracking**: turn off automatic collection of user actions and view visits, keeping only explicit reporting.
* **Sampling**: reduce collection and reporting via the session sample rate.
* **Attribute masking**: use `EventMapper` to modify or drop fields before events are reported, removing any PII that may have leaked in (such as action names or personal information in URLs).
* **Action name masking**: enable `enablePrivacyForActionName` to replace unnamed action names with a placeholder.
See the RUM [Data security](/en/rum/others/data-security) doc for details.
You can disable collection of IP address and geolocation (country/city) data in the app's "user data collection" settings; the change takes effect immediately server-side.
All RUM events can be forwarded through your own proxy server so end-user devices never communicate with Flashduty directly, letting you centrally control egress traffic.
When the user withdraws consent, the SDK stops serving, or an account is closed, you can switch the consent state to `NOT_GRANTED` to stop collection immediately; already-reported data is deleted or anonymized by Flashduty after the agreed retention period expires.
## Integrator obligations
This section details how to implement the [two key requirements](#two-key-requirements-for-compliant-use).
### 1. Privacy policy disclosure
Make sure the app you develop or operate has a privacy policy that meets regulatory requirements, and be sure to clearly inform end users that your app integrates third-party SDK services. In your privacy policy, you should state the purpose, methods, and scope of this SDK's collection and use of personal information, and indicate the SDK's developer/operator name (**Beijing Flashcat Cloud Technology Co.,Ltd.**) along with a link to its privacy policy.
On the app's login/registration page and on first launch, you should inform the user of the privacy policy in clear, plain language through simple, prominent, and easily accessible means such as a pop-up, a text link, or an attachment, so that the user gives a voluntary and explicit indication of consent on a fully informed basis. Where personal information is provided to a third party, you should also list it separately in the "third-party SDK information sharing list".
We provide the following disclosure text as a reference; you may inform users in text or table form (for the table form, refer directly to [Personal information collected](#personal-information-collected) above). Please note that the features and the fields required may differ across SDK versions depending on your choices and configuration; therefore, inform users fully and obtain their consent based on this guide and the actual behavior of the SDK as you integrate and use it. The reference text can be used directly — adjust it to match your actual integration:
```text theme={null}
SDK name: Flashduty RUM SDK
SDK provider: Beijing Flashcat Cloud Technology Co.,Ltd.
Purpose: app crash analysis, performance monitoring, and user experience diagnostics
Personal information collected: device information (model, brand, OS and version,
CPU architecture), network information (connectivity status, network interface type,
uplink/downlink bandwidth, signal strength), app runtime and crash log information, view access and actions
during app usage, and a randomly generated session identifier
Website: https://flashcat.cloud
privacy policy: http://docs.flashcat.cloud/en/compliance/data-security
```
### 2. Deferred initialization
To meet legal and regulatory requirements, make sure you **initialize the SDK only after the user has consented**. To prevent the SDK from starting to collect and use personal information before consent, the SDK provides a deferred-initialization API and a compliant initialization approach — see [Android SDK integration](/en/rum/sdk/android/sdk-integration) and [iOS SDK integration](/en/rum/sdk/ios/sdk-integration) for detailed instructions.
The specific requirements are:
1. **Authorize first, then initialize**: only call the initialization API after the user has read your app's privacy policy and granted authorization, at an appropriate time per your app's needs; if the user declines the privacy policy, you **must not call the initialization API**. When you initialize with the `PENDING` / `.pending` state, the call only completes initialization and buffers data locally — it **sends no personal information to the server** — and reporting starts only after the state is switched to granted.
2. **No permissions, collection, or reporting before consent**: do not dynamically request sensitive device permissions involving personal information before the user accepts the privacy policy; do not collect or report personal information before consent (pay special attention to **Android ID, OAID, IMEI, MAC address, hardware serial number, and the installed-app list**). The SDK does not collect these identifiers by default — see [Information explicitly not collected](#information-explicitly-not-collected).
| Consent state | SDK behavior | Scenario |
| ----------------------------------------- | ------------------------------------------------------------------ | ----------------------------- |
| Android `GRANTED` / iOS `.granted` | Collect and report | The user has consented |
| Android `NOT_GRANTED` / iOS `.notGranted` | Collect no data | The user declined or withdrew |
| Android `PENDING` / iOS `.pending` | Collect but defer reporting until the state is switched to granted | Awaiting user confirmation |
The following shows the "deferred initialization + consent change" code for each platform:
```kotlin Android (Kotlin) theme={null}
import com.datadog.android.Datadog
import com.datadog.android.privacy.TrackingConsent
// Before consent: initialize with PENDING (collect but do not report)
Datadog.initialize(this, configuration, TrackingConsent.PENDING)
// After consent: start reporting
Datadog.setTrackingConsent(TrackingConsent.GRANTED)
// On withdrawal: stop collecting
Datadog.setTrackingConsent(TrackingConsent.NOT_GRANTED)
```
```java Android (Java) theme={null}
import com.datadog.android.Datadog;
import com.datadog.android.privacy.TrackingConsent;
// Before consent: initialize with PENDING (collect but do not report)
Datadog.initialize(this, configuration, TrackingConsent.PENDING);
// After consent: start reporting
Datadog.setTrackingConsent(TrackingConsent.GRANTED);
// On withdrawal: stop collecting
Datadog.setTrackingConsent(TrackingConsent.NOT_GRANTED);
```
```swift iOS (Swift) theme={null}
import DatadogCore
// Before consent: initialize with .pending (collect but do not report)
Datadog.initialize(with: configuration, trackingConsent: .pending)
// After consent: start reporting
Datadog.set(trackingConsent: .granted)
// On withdrawal: stop collecting
Datadog.set(trackingConsent: .notGranted)
```
```objective-c iOS (Objective-C) theme={null}
@import DatadogObjc;
// For initialization, see the iOS SDK integration doc; change consent as follows:
// After consent: start reporting
[DDDatadog setWithTrackingConsent:DDTrackingConsentGranted];
// On withdrawal: stop collecting
[DDDatadog setWithTrackingConsent:DDTrackingConsentNotGranted];
```
The snippets above show only the minimal code needed for deferred initialization. For the full initialization parameters, integration steps, and consent APIs per platform, see the corresponding docs:
* Android: [SDK integration](/en/rum/sdk/android/sdk-integration) · [Advanced configuration · User tracking consent](/en/rum/sdk/android/advanced-config#user-tracking-consent)
* iOS: [SDK integration](/en/rum/sdk/ios/sdk-integration) · [Advanced configuration](/en/rum/sdk/ios/advanced-config)
## Data storage and security
Data collected by the SDK is reported only to the Flashduty server you configure and is used solely to provide monitoring services to you. It is **not shared with any other third party** and is **not used for** advertising, user profiling, or cross-app tracking. Throughout the data lifecycle, Flashduty applies the following safeguards:
* **Transport security**: all reported data is transmitted over HTTPS/TLS.
* **Storage security**: data is stored on compliant servers within mainland China, with encryption, access control, and security auditing.
* **Retention and deletion**: data is stored for the agreed retention period and deleted or anonymized after expiry.
* **Cross-border transfer**: no cross-border transfer occurs without your explicit consent or unless otherwise required by laws and regulations.
For the full security measures, retention periods, and cross-border transfer terms, see the [Data protection agreement](/en/compliance/data-security) and the RUM [Data security](/en/rum/others/data-security) doc.
## Compliant integration checklist
Add the SDK's name, provider, collected information, and purpose to your app's privacy policy.
Ensure the SDK is not initialized and no data is reported before the user consents (or use the `PENDING` state).
Register the personal information fields and purposes from this guide in your app's third-party sharing list / filing materials.
Provide an entry to withdraw consent in your app settings, and call `setTrackingConsent(NOT_GRANTED)` upon withdrawal.
Review `setUserInfo` and custom attributes to ensure no sensitive personal information is passed to the SDK.
## Contact us
This SDK is provided by **Beijing Flashcat Cloud Technology Co.,Ltd.** If you have any questions, feedback, or complaints about how this SDK processes personal information, or if you need to exercise your data-subject rights, you can contact us via:
Scan to add our WeCom for one-on-one technical support
Scan to add our business manager on WeCom
Sign in to the console and submit feedback in the bottom left corner
[support@flashcat.cloud](mailto:support@flashcat.cloud)