SDKs response
This page explains the reasons why an SDK is terminated. To do this, check the instance of the SDKFailure object class present in the result object.
Example
The following example shows how to discover and handle the shutdown reason for the DocumentDetector SDK:
Security returns
We are constantly taking actions to make the product more and more secure, mitigating many attacks observed in the capture processes and, consequently, reducing as many possible identity frauds as possible. The errors described here are returned in the message
field of the SecurityReason
class.
Error 100
Represents SDK blocking emulated devices.
The use of emulators is very common by fraudsters nowadays, because of the possibility to access any existing device, opening a huge range of possibilities for new frauds. Because of this, by default, the SDKs perform this blocking.
If you want to disable this validation, use the .setUseEmulator(bool use)
method in the SDK Builder.
Error 200
Represents the blocking of devices with root privileges by the SDK.
The use of root devices is the main means of fraud today, because of the possibility of accessing a device with extra privileges, allowing the fraudster to access hidden properties, as well as the possibility of modifying and circumventing the entire security system behind the SDKs. Because of this, by default, the SDKs perform this blocking.
If you want to disable this validation, use the .setUseRoot(bool use)
method in the SDK Builder.
Error 300
Represents the locking of devices with developer mode active.
Using devices in developer active mode allows a user to access unique development settings, such as the ability to debug applications using USB cables. Because of this, by default, the SDKs perform this blocking.
If you want to disable this validation, use the method .setUseDeveloperMode(bool use)
in the SDK Builder.
Error 400
Represents the locking of devices with Android Debug Bridge enabled.
The ADB command facilitates a variety of device actions, such as installing and debugging apps and provides access to a Unix shell. Because of this, by default, the SDKs perform this locking.
If you want to disable this validation, use the .setUseAdb(bool use)
method in the SDK Builder.
Error 500
Represents the locking of devices with debug mode enabled.
Using devices with debug mode enabled allows a user to debug applications using USB cables, allowing them to understand and test different ways to bypass the SDK flow. Because of this, by default, the SDKs perform this blocking.
If you want to disable this validation, use the .setUseDebug(bool use)
method in the SDK Builder.
Error 600 (soon)
Represents the blocking of devices with fraudulent app signatures.
Signature verification blocks reverse engineering attacks and all other malicious attacks that can be done after this process in which the app has its original signature changed. Because of this, SDKs perform this blocking by default.
If you want to disable this validation, use the .checkAppSignature(bool use)
method in the SDK Builder.
Last updated