Fraud Detection:Device Fraud Detection SDK FAQ

What is the SDK size?

The SDK size varies by platform:

• Android: A single-architecture SO file is approximately 3.4 MB. The AAR package includes SO files for three architectures and totals around 10 MB. Because an APK packages only the SO file for the target architecture, the actual size increase is approximately 3.4 MB.

• iOS: The single-architecture package is approximately 2.7 MB.

• HarmonyOS: The package is approximately 3 MB.

To ensure anti-reverse-engineering protection and data security during network transmission, the Device Fraud Detection SDK uses extensive code obfuscation, inflation, and encryption/decryption operations, which results in a relatively large SDK size.

What is a deviceToken?

A deviceToken is a string credential that the SDK generates for the current device. The client obtains the token and sends it to the server along with the business request. The business server then uses it to retrieve the device fingerprint information and risk labels from Alibaba Cloud Fraud Detection. Think of the deviceToken as a pickup code rather than the device information itself: after the SDK completes environment detection and fingerprint collection, it reports the raw data to the server for storage, and the deviceToken is simply an index pointing to that data. Under normal conditions, the token therefore carries little device information. The exception is the degraded scenario — when the token is obtained before initialization is complete, the SDK redundantly packs the already-collected fields into the token body, which is why a degraded token is noticeably longer. For details, see "Why can't you call getDeviceToken immediately after initialization?".

What is the validity period of a deviceToken? Can I use the same deviceToken for multiple server-side API calls?

A deviceToken is valid for 7 days and can be called multiple times. It is recommended to query once per deviceToken.

Why can't you call getDeviceToken immediately after initialization?

The initialization interface is asynchronous. A method return only indicates the process has started, not that it is ready. In the background, the SDK still needs to complete environment detection, fingerprint collection, and a handshake with the server. On a normal network, this takes approximately 1 to 2 seconds; weak networks, low-end devices, or first-time installations will take longer. getDeviceToken retrieves the product of initialization: once the handshake is complete, the device information is stored on the server and a compact token is returned. If called before this, the SDK can only use degraded logic, packing the already-collected fields redundantly into the token body.

Degradation has two consequences. First, identification capability is reduced — the token carries incomplete device information, which degrades device identification and risk assessment on the server side. Second, the token becomes significantly longer — redundant fields multiply the length, which not only increases network transmission overhead but, if the business side has length constraints on the token (database fields, HTTP headers, URL parameters, etc.), may cause truncation and more subtle issues.

The correct integration approach, in order of recommended priority:

1. Call getDeviceToken in the initialization success callback. This is the only deterministic approach — it does not depend on any assumption about initialization time and naturally adapts to weak networks and low-end devices.

2. If attaching a callback is truly not possible, use a fixed delay as a fallback: call after an interval of no less than 3 seconds. This interval is an empirical safety margin above the typical initialization time, not a precise threshold. It reduces the probability of degradation but cannot eliminate it.

Which CPU architectures does the Device Fraud Detection SDK support?

• Android: supports arm, armv7, and arm64 architectures.

• HarmonyOS: supports arm64 architecture.

• iOS: supports arm64 and x86_64 architectures.