Fraud Detection:Device Fraud Detection SDK FAQ

Quelle est la taille du SDK ?

La taille du SDK varie selon la plateforme :

• Android : un fichier SO pour une seule architecture pèse environ 3,4 Mo. Le package AAR inclut des fichiers SO pour trois architectures et atteint environ 10 Mo. Comme un APK n'embarque que le fichier SO correspondant à l'architecture cible, l'augmentation réelle de la taille est d'environ 3,4 Mo.

• iOS : le package pour une seule architecture pèse environ 2,7 Mo.

• HarmonyOS : le package pèse environ 3 Mo.

Pour garantir la protection contre la rétro-ingénierie et la sécurité des données lors des transmissions réseau, le SDK Device Fraud Detection repose sur une obfuscation poussée du code, ainsi que sur des opérations de gonflement et de chiffrement/déchiffrement, ce qui explique sa taille relativement importante.

Qu'est-ce qu'un deviceToken ?

Un deviceToken est une chaîne d'identification générée par le SDK pour l'appareil actuel. Le client obtient ce jeton et l'envoie au serveur avec la requête métier. Le serveur métier l'utilise ensuite pour récupérer l'empreinte numérique de l'appareil et les étiquettes de risque auprès d'Alibaba Cloud Fraud Detection. Considérez le deviceToken comme un code de retrait plutôt que comme les informations de l'appareil elles-mêmes : une fois que le SDK a terminé la détection de l'environnement et la collecte de l'empreinte, il transmet les données brutes au serveur pour stockage, et le deviceToken sert simplement d'index pointant vers ces données. Dans des conditions normales, le jeton contient donc peu d'informations sur l'appareil. La seule exception concerne le scénario dégradé : lorsque le jeton est obtenu avant la fin de l'initialisation, le SDK embarque de manière redondante les champs déjà collectés dans le corps du jeton, ce qui explique pourquoi un jeton dégradé est nettement plus long. Pour plus de détails, consultez la section « Pourquoi ne pas appeler getDeviceToken immédiatement après l'initialisation ? ».

Quelle est la durée de validité d'un deviceToken ? Puis-je utiliser le même deviceToken pour plusieurs appels d'API côté serveur ?

Un deviceToken est valide pendant 7 jours et peut être utilisé plusieurs fois. Il est recommandé d'effectuer une seule requête par deviceToken.

Pourquoi ne pas appeler getDeviceToken immédiatement après l'initialisation ?

L'interface d'initialisation est asynchrone. Le retour d'une méthode indique seulement que le processus a démarré, pas qu'il est prêt. En arrière-plan, le SDK doit encore terminer la détection de l'environnement, la collecte de l'empreinte et l'établissement d'une liaison avec le serveur. Sur un réseau normal, cette opération prend environ 1 à 2 secondes ; les réseaux faibles, les appareils bas de gamme ou les premières installations nécessitent plus de temps. getDeviceToken récupère le résultat de l'initialisation : une fois la liaison établie, les informations de l'appareil sont stockées sur le serveur et un jeton compact est renvoyé. Si vous appelez la méthode avant cette étape, le SDK ne peut utiliser qu'une logique dégradée, en embarquant de manière redondante les champs déjà collectés dans le corps du jeton.

La dégradation a deux conséquences. Premièrement, la capacité d'identification est réduite : le jeton transporte des informations incomplètes sur l'appareil, ce qui altère l'identification de l'appareil et l'évaluation des risques côté serveur. Deuxièmement, le jeton devient significativement plus long : les champs redondants multiplient la taille, ce qui non seulement augmente la charge de transmission réseau, mais peut aussi, si le côté métier impose des contraintes de longueur sur le jeton (champs de base de données, en-têtes HTTP, paramètres URL, etc.), entraîner des troncatures et des problèmes plus subtils.

Voici les bonnes pratiques d'intégration, par ordre de priorité recommandée :

1. Appelez getDeviceToken dans le callback de succès de l'initialisation. Cette approche est la seule déterministe : elle ne dépend d'aucune hypothèse sur la durée d'initialisation et s'adapte naturellement aux réseaux faibles et aux appareils bas de gamme.

2. S'il est vraiment impossible d'attacher un callback, utilisez un délai fixe en solution de repli : effectuez l'appel après un intervalle d'au moins 3 secondes. Cet intervalle constitue une marge de sécurité empirique supérieure au temps d'initialisation typique, et non un seuil précis. Il réduit la probabilité de dégradation, mais ne l'élimine pas.

Quelles architectures CPU le SDK Device Fraud Detection prend-il en charge ?

• Android : prend en charge les architectures arm, armv7 et arm64.

• HarmonyOS : prend en charge l'architecture arm64.

• iOS : prend en charge les architectures arm64 et x86_64.