Skip to main content
About Dependencies and Package NamesFlashduty Android SDK is fully compatible with the Datadog open-source protocol. In build.gradle, use cloud.flashcat group for dependencies, but in Kotlin/Java code, import classes from the com.datadog.android package. You can seamlessly leverage Datadog ecosystem documentation, examples, and best practices while enjoying Flashduty platform services.
Flashduty Android RUM SDK provides rich advanced configuration options to help you customize data collection and context information based on business needs.
Supported Configuration Scenarios:
  • Enrich user sessions - Add custom views, actions, resources, and error information
  • Protect sensitive data - Mask personally identifiable information and sensitive data
  • Associate user sessions - Link user sessions with internal user identifiers
  • Control data volume - Optimize data collection through sampling and event filtering
  • Enhance context - Add custom attributes to data

Enrich User Sessions

Custom Views

When using ActivityViewTrackingStrategy or FragmentViewTrackingStrategy, the RUM SDK automatically tracks views. You can also manually send custom RUM views when a view becomes visible or interactive.
Parameter Description:
  • viewKey (String) - Unique identifier for the view, same viewKey used for startView() and stopView()
  • viewName (String) - Name of the view
  • attributes (Map<String, Any?>) - Attributes attached to the view (optional)

Custom Actions

In addition to auto-tracked user interactions, you can track specific custom user actions (like clicks, swipes, likes).

Custom Resources

In addition to auto-tracked resources, you can manually track specific custom resources (like network requests, third-party library loading).

Custom Errors

To record specific errors, notify the RUM SDK when an exception occurs:
For more error reporting details, see Android Error Reporting.

Custom Timing

In addition to RUM SDK’s default performance metrics, you can use the addTiming API to measure the duration of key operations. Timing is an offset relative to the current RUM view start time.
After setting timing, access it via @view.custom_timings.<timing_name>, e.g., @view.custom_timings.hero_image.

Set User Information

The RUM SDK supports standard user information.
Only standard user fields are supported: id, name, email, and anonymous_id. Other user attributes are not supported. If needed, configure them under context.

Event and Data Management

Clear All Data

Use clearAllData to clear all unsent data currently stored in the SDK:

Stop Data Collection

Use stopInstance to stop collecting data and clear all local data:
After you call stopInstance(), the SDK stops working entirely. You have to initialize it again to resume data collection.

Control Event Batch Upload

The RUM SDK uploads events in batches automatically. You can control that behavior with configuration parameters:

Set Remote Log Threshold

You can define a minimum log level for remotely recorded messages. Logs below that level are not sent to Flashduty:
With a Log.WARN threshold, only WARN and ERROR logs are uploaded. DEBUG and INFO logs are filtered out.

Track Custom Global Attributes

Beyond the default attributes the RUM SDK captures automatically, you can attach extra context to RUM events, such as custom attributes.
What custom attributes are for:
  • Filter and group user behavior by business information, such as cart state, user tier, or marketing campaign
  • Follow the browsing path of a specific user
  • Understand which users are hit hardest by an error
  • Monitor performance for your most important users

Track User Sessions

To identify user sessions, call the setUserInfo API after initializing the SDK:
Only the standard user fields are supported: id, name, email and anonymous_id. Other user properties are not. If you need more, put them in the context field.
Parameters:
  • id (String) - Unique user identifier
  • name (String) - Friendly user name, shown in the RUM UI by default
  • email (String) - User email, shown when no name is available
  • All of these are optional, but you should provide at least one

Track Attributes

Global attributes are attached to every RUM event and are useful for adding shared context. Add a global attribute:
Remove a global attribute:

Track Widgets

Widgets are not tracked automatically. To monitor widget interactions, call the API yourself.

Initialization Parameters

When you initialize the Flashduty Android SDK, Configuration.Builder gives you several options.

Automatically Track Views

To track views (activities and fragments) automatically, call useViewTrackingStrategy during initialization:

Automatically Track Network Requests

To track HTTP requests automatically, see the OkHttp interceptor setup in the SDK integration guide.

Automatically Track Apollo GraphQL Requests

If you use the Apollo GraphQL client for network calls, you can enable automatic tracking.
1

Add the Apollo dependency

Add the dependency to your app’s build.gradle file:
build.gradle
Check the Maven Central versions page for the latest version number.
2

Configure the Apollo client

Flashduty tracing headers are added to your GraphQL requests automatically, which makes them traceable.
Limitations:
  • Only Apollo version 4 is supported
  • Only query and mutation operations are tracked; subscription operations are not
Send GraphQL payloads (optional):

Automatically Track Long Tasks

Long-running work on the main thread can hurt your app’s visual performance and responsiveness. The SDK can detect and track long tasks automatically.
The default threshold is 100ms. Adjust it to match your app’s performance requirements.

Modify or Discard RUM Events

To modify some attributes of a RUM event before it is batched, or to discard events entirely, provide an implementation of EventMapper<T> at initialization.

Modifiable Event Attributes

When you implement the EventMapper<T> interface, only some attributes can be modified for each event type:
If your EventMapper<T> implementation returns null, the event is discarded and never sent to Flashduty.

Example: Discard Sensitive Errors

Get the RUM Session ID

Retrieving the RUM session ID is useful for troubleshooting. You can attach it to support requests, emails or error reports so the support team can find the user’s session in Flashduty.
You can read the RUM session ID at runtime without waiting for the sessionStarted event.

Sampling Control

By default, RUM collects data for every session. You can reduce the number of collected sessions by setting a sample rate through the sessionSampleRate parameter.
Sample rate range: 0.0 - 100.0
  • 100.0 - Collect every session (default)
  • 50.0 - Collect 50% of sessions
  • 0.0 - Collect no sessions
Sampled-out sessions collect no page views and none of the related telemetry data.

Remote configuration: adjust the sample rate from the console

Since 0.7.0, the session sample rate can be changed on the Remote configuration page of the Flashcat console without shipping a new release of your app. The feature is off by default; turn it on at initialization:
How a change takes effect:
  • The SDK asks the console for the configuration once at startup and once whenever a new session starts. What it receives is used to draw the next session; a session already under way is never redrawn.
  • The exception is a rate that crosses zero (from 0 to non-zero, or from non-zero to 0): the running session ends immediately and the next one is drawn under the new rate, so an emergency stop or a restart does not wait for sessions to rotate.
  • When the request fails, times out or returns an unreadable response, the SDK keeps the values already in use; before the first configuration ever arrives, the value passed to setSessionSampleRate applies. The configuration is cached on the device, so the first session of the next cold start already uses it.
  • The request carries only the client token, the environment, the app version and the SDK version, never user data, so it is not gated by the tracking consent state.
  • In a private deployment the configuration endpoint sits beside the RUM intake under /config (for an intake of https://host/api/v2/rum, it is https://host/api/v2/rum/config). When you use useCustomEndpoint, make sure your gateway lets that path through.

Override the draw from your app

To guarantee that certain users are always collected (internal testers, a user whose issue you are investigating), setBeforeSampling lets the app have the last word before each draw. Return null to keep the incoming rate. A value outside 0..100, or a callback that throws, also leaves the incoming rate in place and never disrupts collection.
While the app is running you can also call setForcedSession() at any time to collect every session of this user from now until the process ends:

Read the console’s custom configuration

The values published under “Custom configuration” on the Remote configuration page are delivered to the SDK verbatim and can be read with getRemoteConfig(). The SDK never interprets them; what they mean is entirely up to your app. It returns null when nothing is published or remote configuration is off.
Custom configuration is visible to every client running the SDK. Never put secrets, tokens or personal data in it.
To comply with privacy regulations such as GDPR and CCPA, RUM lets you set the user tracking consent state at initialization.
If you initialize with TrackingConsent.PENDING, the SDK starts collecting data but sends nothing until the consent state changes to GRANTED.
You can change the consent state after initialization through the setTrackingConsent API:

Best Practices

  • Call startView and stopView in the right lifecycle methods so views are not tracked twice
  • Use a unique viewKey for each view
  • When tracking resources manually, pair every startResource with a matching stopResource or stopResourceWithError
  • Avoid tracking internal resources or requests that fire very frequently
  • Only the attributes listed in the tables above can be modified; changes to any other attribute are ignored
  • Return null to discard the whole event
  • Tune the sample rate and batch upload frequency together to balance data volume against overhead
  • Avoid slow work inside event callbacks

SDK Integration

Learn how to quickly integrate the RUM SDK

Data Collection

Learn about data types and attributes collected by the SDK

Compatibility

Learn about SDK compatibility requirements