# Integrated Requirement

# Compliance Explanation

Please note that when integrating SDK products provided by the TrustDecision in the APP of your company:

1.1 According to the user's information protection regulations, before your users start the App for the first time and start collecting information, your company should fully inform the user of the purpose, method, and scope of collecting, using, and sharing the user's personal information with a third party through an interactive interface or design (such as a pop-up window of the privacy policy), and obtain the express consent of the end user.

1.2 To provide business security and risk control services to your company, the TrustDecision SDK will collect, process, and use the identification information（IMEI/IDFA）, AndroidID, IMSI, MEID, MAC address, SIM card serial number, device type, device model, system type, geographical location, login IP address, application list, running process, sensor information(light sensor, gravity sensor, magnetic field sensor, acceleration sensor, gyroscope sensor) and other device information of the user's device. To ensure compliance with your use of related services, the aforementioned privacy policy should cover the authorization of TrustDecision SDK to provide services and collect, process, and use relevant information. The following terms are for your reference. The specific expression can be determined by your company according to the overall framework and content of your privacy agreement:

TrustDecision SDK: For business security and risk control, our company uses the TrustDecision SDK. The SDK needs to obtain the information of your devices, such as （IMEI/IDFA）, AndroidID, IMSI, MAC address, SIM card serial number, device type, device model, system type, geographic location, login IP address, application list, running process, sensor information(light sensor, gravity sensor, magnetic field sensor, acceleration sensor, gyroscope sensor) and other related device information, for fraud risk identification.

Privacy Protocol: https://www.trustdecision.com/legal/privacy-policy (opens new window)

# Environment

Items	Description
Supported System Versions	Support mainstream models, Android 4.4 and above systems
System library dependency	armeabi-v7a, arm64-v8a, x86

# Integrate Steps

# Integrate SDK

Note: For customers who have integrated SDK in project libs, please delete the old version SDK first when upgrading the new version SDK, and if there are so libraries integrated with the old version, they also need to be deleted at the same time.

SDK access sample code : https://github.com/trustdecision/mobrisk-android-sample](https://github.com/trustdecision/mobrisk-android-sample)

# add warehouse

First, please add the maven library configuration to build.gradle in the project root directory

allprojects {
    repositories {
        ...
        mavenCentral()
    }
}

If your Gradle version is 7 or higher, add these lines to your settings.gradle

repositories {
        ...
        mavenCentral()
}

# add dependencies

Add dependencies to app/build.gradle of the project, as shown in the figure:

dependencies {
    // fingerprint
    implementation 'com.trustdecision.android:mobrisk:4.2.4.2'
 }

If compliance issues are encountered, we can also exclude the collection of related modules during the dependency phase, as follows:

dependencies {
    // fingerprint
    implementation('com.trustdecision.android:mobrisk:4.2.4.2'){
    	// after removal, sdk does not get the list of installation packages
        exclude group: 'com.trustdecision.android', module: 'packagelist'
        // after removal, sdk will not collect READ_PHONE_STATE related information
        exclude group: 'com.trustdecision.android', module: 'readphone'
    }
 }

# ABI type

The SDK currently supports three ABI types: armeabi-v7a, arm64-v8a, and x86. It is recommended that the accessor party add an abiFilters configuration to select the required architecture type in the app/build.gradle file. Example

defaultConfig {
    ........
    ndk {
       abiFilters 'armeabi-v7a', 'arm64-v8a'
    }
}

For the specific architecture, please refer to the architecture you need to support!

# Configuration AndroidManifest.xml

Declare the following permissions in the AndroidManifest.xml file under the application module

<manifest>
   <!--Compulsory permissions-->
   <uses-permission android:name="android.permission.INTERNET"/>
   <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
   <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>

   <!--The following permissions are optional. If this part of the authority is not declared, the acquisition of some device information will be abandoned, which will have a certain effect on data analysis and the accuracy of the fingerprint of the device fingerprint-->
   <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
   <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
   <uses-permission android:name="android.permission.READ_PHONE_STATE" />
   <!-- This permission is required for Android 11 and above to obtain the installation package list. Collecting the installation package list involves risk and compliance. Whether this permission is required is optional for the business party
select -->
   <uses-permission android:name="android.permission.QUERY_ALL_PACKAGES"
        tools:ignore="QueryAllPackagesPermission" />
</manifest>

Dynamic application permissions: Android 6.0 or above requires dynamic application permissions. Dynamic application permissions code must be placed before the initial SDK. The code example is as follows:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    requestPermissions(new String[]{
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION,
            Manifest.permission.READ_PHONE_STATE
    }, 100);
}

# How to use the SDK

Precautions

Ensure that the SDK is initialized after the user agrees to the privacy agreement, so as to avoid the occurrence of SDK initialization and collection without the user's consent to the privacy agreement, which may cause compliance risks.

SDK configuration

The Trustdecision SDK uses the TDRisk.Builder method to configure and set the SDK initial parameters, and provides the setting results as initialization parameters to the SDK initialization method initWithOptions().

TDRisk.Builder must be configured with parameters as follows

Key	Definition	Description	Sample code
partner	Partner code	Partner, please contact TrustDecision to obtain	builder.partnerCode("partner")
appKey	App key	Configure AppKey with TrustDecision, please contact TrustDecision Operations to get it The appkey creation requires the user to provide the application package name and a lowercase sha256 signature. ⚠️ Do not use the same value for package name signatures of different applications	builder.appKey("appKey")
appName	App name	AppName, please contact TrustDecision to obtain	builder.appName("appName")
country	Country code	TDRisk.COUNTRY_US means North America TDRisk.COUNTRY_FRA means Europe TDRisk.COUNTRY_SG means Singapore TDRisk.COUNTRY_CN means China	builder.country(TDRisk.COUNTRY_CN)

We also provide optional parameter configuration, see the attached table for details (list of optional parameters for initial configuration)

SDK Sample Code When the application starts, for example, the following method is called in the application class of the Application (Android 6.0 and above to ensure that you have applied).

# Method 1 (recommended method): Obtain blackbox through getBlackBox() method

// SDK init option
TDRisk.Builder builder = new TDRisk.Builder()
/*************************** Must ***************************/
.partnerCode("demo")            // Partner code, such as demo, please fill in your partner, get from trustDecision
.appName("appName")             // app Name, such as appName, please fill in your app Name
.appKey("appKey")		// configure AppKey, please contact TrustDecision Operations to obtain it 
.country(TDRisk.COUNTRY_CN);    // Country parameter，E.g: cn、sg、us、fra
/*************************** Must ***************************/

// init Mob-Risk SDK
if(User agrees with the privacy agreement){
   TDRisk.initWithOptions(getApplicationContext(), builder);
}

⚠️Precautions: You must ensure that getBlackBox is called after initWithOptions. Get blackbox when your business needs it

String blackbox = TDRisk.getBlackBox();

# Method 2: Obtain the blackbox in onEvent through the callback method callback

// SDK init option
TDRisk.Builder builder = new TDRisk.Builder()
/*************************** Must ***************************/
.partnerCode("demo")            // Partner code, such as demo, please fill in your partner, get from trustDecision
.appName("appName")             // app Name, such as appName, please fill in your app Name
.appKey("appKey")		// configure AppKey, please contact TrustDecision Operations to obtain it 
.country(TDRisk.COUNTRY_CN)     // Country parameter，E.g: cn、sg、us、fra
/*************************** Must ***************************/

// fingerprint init
.callback(new TDRiskCallback() {
  @Override
  public void onEvent(String blackbox) {
    // The callback here is in the thread thread
    // In the case of normal, the results will return within 200-300ms.
    // In the case of abnormality, it will return after the timeout (the longest 15S default).
    Log.i("TDRiskDemo", "blackbox: " + blackbox);
  }
});

// init Mob-Risk SDK
if(User agrees with the privacy agreement){
   TDRisk.initWithOptions(getApplicationContext(), builder);
}

# The difference between the two ways

The first method is to obtain the blackbox synchronously. The advantage is that the blackbox can be guaranteed to be obtained (in some cases, it is a downgraded blackbox). If you call getBlackBox on the main thread, you need to pay attention to the time-consuming problem.
The second method is to obtain blackbox asynchronously. The advantage is that the process will not be blocked and there is no time-consuming problem. The disadvantage is that the initialization has not been completed when calling the getBlackBox method, and the blackbox cannot be obtained. It should be noted that the callback result is not in the main thread, and it is forbidden to operate the UI in the callback.

After the SDK reports the data successfully, under normal circumstances, the length of the result returned by getBlackbox() is a 26-bit string. For example: rWPGX1678775227I9NCwcuVJCb Under abnormal circumstances, the length is about 5000 characters. For details, please check Overview (opens new window)

After executing initWithOptions initialization successfully, the following log will be printed in logcat:

TD_JAVA: tongdun sdk load success
TD_JAVA: tongdun sdk init success

# Get SDK Version

Sample Code

// Get SDK Version
TDRisk.getSDKVersion()

# Other Instructions

Confuse packaging. If the developer needs to use Proguard for confusion, please add the following code to the proguard configuration file:

#TrustDecision
-keep class cn.tongdun.**{*;}

# Initial configuration optional parameter list

Key	Definition	Description	Sample Code
setHttpTimeout	SDK timeout interval configuration(unit: millisecond)	Timeout interval of network request callback after SDK initialization. Defaults is 15 * 1000ms.	builder.httpTimeout(5000)
callback	SDK asynchronous callback configuration	After the SDK initializes the collection and reporting, it returns blackbox according to the network request result. Successful request: return non-degraded blackbox Request failure: return degraded blackbox	builder.callback()
collectLevel	Downgrade blackbox collection field length configuration	The downgraded blackbox will be longer. This configuration can control the downgraded blackbox length 1. TDRisk.COLLECT_LEVEL_L (default value, the downgraded length is about 5000 characters) 2. TDRisk.COLLECT_LEVEL_M (the downgraded length is about 2000 characters)	builder.collectLevel(TDRisk.COLLECT_LEVEL_L)
blackBoxMaxSize	blackbox maximum length	The default length is Integer.MAX_VALUE, it will increase according to the actual device situation)	builder.blackBoxMaxSize(3000)
customProcessName	custom process name	change the name of the process	builder.customProcessName("td")
forceTLSVersion	Whether https is mandatory to use TLS-v1.1 version	The default is not mandatory, and the developer can set the corresponding settings according to the specific situation	builder.forceTLSVersion(true)
disableDebugger	Whether to allow debugging	After the SDK is integrated, the app allows debugging by default, and the developer can make corresponding settings according to the specific situation.	builder.disableDebugger()
disableRunningTasks	Whether to allow getting running tasks	The default is to allow access, you can call this method to close	builder.disableRunningTasks()
disableGPS	Do not collect GPS related information	If you don't want to get location related information, you can cancel the collection of location related information by this method. ⚠️ When this option is configured, the app has location rights and the SDK will not collect location related information	builder.disableGPS()
disableSensor	Do not collect sensor information	If you do not collect sensor-related information, you can cancel the collection of relevant information through this method。	builder.disableSensor()
disableReadPhone	Do not collect READ_PHONE_STATE related information	By default, information that requires READ_PHONE_STATE permission is collected, and this method can be called to close it	builder.disableReadPhone()
disableInstallPackageList	Do not collect the list of installation packages	By default, the list of installation packages is collected, and this method can be called to close	builder.disableInstallPackageList()

# FAQ

Q1: Why is the blackbox field obtained longer?

A1: The length of blackbox is 26 bytes under normal circumstances, but due to poor network conditions or when the calling interval of functions TDRisk.initWithOptions() and TDRisk.getBlackBox() is short, black_box will be accompanied by some device information and the length will increase to 1500 -3000 bytes.

Q2: Why is some information in the incident empty?

A2: The device information acquisition may fail due to the short interval from SDK initialization to device data acquisition. Do not obtain device information immediately after initialization

Q3: Why is the real IP of some events empty?

A3: When the SDK fails to upload the device information (timeout or the network is blocked), it will automatically switch to offline mode. In this case,TrustDecision cannot obtain the real IP.

Q4: Why does the app on a mobile phone of some architecture collapse?

A4: SDK supports a variety of architectures. If the APP collapses, it may be that the SO directory of the corresponding architecture may not be introduced to the corresponding SO file. Please note that your NDK supports architecture.

← Overview iOS →