SDK developer compliance guide

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 and the RUM 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:

① Privacy policy disclosure

Disclose in your app’s privacy policy that the SDK is integrated and what personal information it collects. See Privacy policy disclosure.

② Deferred initialization

Do not initialize the SDK or report any data before the user accepts your privacy policy. See Deferred initialization.

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

How the SDK processes personal information

The following is the factual basis for completing your privacy policy disclosure.

Personal information collected

To support crash analysis, performance diagnostics, and user experience monitoring, the SDK automatically collects the following information. Apart from “app runtime information”, all collection items can be disabled or masked via configuration (see 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).

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

The SDK only requests the network permissions necessary for monitoring; it requests no sensitive permissions.

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

Data minimization and de-identification

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.

Controllable collection (disable / sample / mask)

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 doc for details.

IP and geolocation can be disabled

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.

Proxy reporting

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.

Withdrawal of consent and data destruction

Integrator obligations

This section details how to implement the two key requirements.

1. Privacy policy disclosure

Add the SDK to the “third-party SDK information sharing list” in your app’s privacy policy. Reference text:

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

Do not call SDK initialization before the user accepts your privacy policy; or initialize with the PENDING state (collect but do not report), then switch to GRANTED after consent.

Consent state	SDK behavior	Scenario
`GRANTED`	Collect and report	The user has consented
`NOT_GRANTED`	Collect no data	The user declined or withdrew
`PENDING`	Collect but defer reporting until the state changes to `GRANTED`	Awaiting user confirmation

import com.datadog.android.Datadog
import com.datadog.android.privacy.TrackingConsent

// Before consent: do not initialize, or initialize with PENDING
Datadog.initialize(this, configuration, TrackingConsent.PENDING)

// After the user taps "Agree" in the privacy dialog:
Datadog.setTrackingConsent(TrackingConsent.GRANTED)

// When the user withdraws consent in settings:
Datadog.setTrackingConsent(TrackingConsent.NOT_GRANTED)

For the full consent-state usage per platform, see Android advanced configuration · User tracking consent and the corresponding docs.

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. Data is stored on compliant servers within mainland China, transmitted over HTTPS/TLS, and protected by access control and auditing. For the full security measures, retention periods, and cross-border transfer terms, see the Data protection agreement and the RUM Data security doc.

Compliant integration checklist

Update your privacy policy

Add the SDK’s name, provider, collected information, and purpose to your app’s privacy policy.

Defer initialization

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 a withdrawal entry

Provide an entry to withdraw consent in your app settings, and call setTrackingConsent(NOT_GRANTED) upon withdrawal.

Avoid passing in sensitive information

Review setUserInfo and custom attributes to ensure no sensitive personal information is passed to the SDK.

​Two key requirements for compliant use

① Privacy policy disclosure

② Deferred initialization

​Division of compliance responsibilities

​How the SDK processes personal information

​Personal information collected

​Information explicitly not collected

​Device permissions requested

​Data handling rules and commitments

​Integrator obligations

​1. Privacy policy disclosure

​2. Deferred initialization

​Data storage and security

​Compliant integration checklist

Two key requirements for compliant use

Division of compliance responsibilities

How the SDK processes personal information

Personal information collected

Information explicitly not collected

Device permissions requested

Data handling rules and commitments

Integrator obligations

1. Privacy policy disclosure

2. Deferred initialization

Data storage and security

Compliant integration checklist