# Client SDK FAQ
# What is the client SDK reporting strategy?
The data of the native client SDK (including unity, unreal, fluent, etc.) will be cached in the local database first, and the data reporting will be triggered under the following conditions:
-App back to the background
-Report once a minute (can be set in Ta background)
-More than 100 cached data trigger reporting (can be set in Ta background)
-Actively call flush interface
Small programs, small game SDKs and JavaScript SDKs will be reported in real time without local cache.
# What is the value logic of device ID?
The device ID value logic of the native client side SDK (including Unity, Unreal, Flutter, etc.) is as follows:
- Android: take Android ID
For systems under Android 8.0, the Android ID is the unique identifier of the device. It will not be changed until you refresh the machine or restore the factory settings. All applications are shared. For Android 8.0 and later, each combination of the app signing key, user, and device has a unique ANDROID_ID value. Therefore, apps running on the same device but with different signing keys will no longer see the same Android ID (even for the same user). A special case: if the user installs the APP device below 8.0, then uninstalls it, upgrades to 8.0 and reinstates the application, the Android ID will be different from before; if there is no reinstall, then the Android ID will not change.
- iOS: Take IDFV first, if not, use random UUID. For the first time, the device ID value will be stored in the keychain and will not change, even if the IDFV changes subsequently.
The Mini Program, Mini Games, and JavaScript interfaces cannot obtain similar device numbers, and use a randomly generated ID as the device ID. If the user deletes the cache, the device ID will change.
# What is the minimum system version supported by the client side SDK?
The minimum version supported by the client side SDK is Android 4.0 and iOS 8.0
# How to investigate and report problems?
General problems can be quickly located through the client side log. We have introduced how to open the client side log in each access guide.
In Android, you can turn on client side logging by calling the enableTrackLoginterface. You can filter Android SDK logs through ThinkingAnalytics.
ThinkingAnalyticsSDK.enableTrackLog(true);
In iOS, you can turn on log printing by calling the setLogLevelinterface, and filter the logs iOS the SDK by KING.
[ThinkingAnalyticsSDK setLogLevel:TDLoggingLevelDebug]
After opening the log, you can send the log to our technical support engineer to help locate the problem.
If you are not sure whether the reporting address is correct, you can check the accessibility of the reporting address by checking the check interface. Visit https://YOUR_RECEIVER_URL/health-check, and the page returns ok to indicate that the receiving end address is configured correctly.
In addition, through the function of the event tracking management module, problems in the data reporting process can also be easily located.
# What are the considerations for reporting data through the Unity SDK?
- The initialization of our SDK is completed in Awake (), so the call cannot be triggered in Awake.
- by default, all interfaces can only be invoked in the main thread.
- We judge whether the app enters the foreground or retreats to the background through the component life cycle of Android system. However, unity cannot guarantee that the SDK is initialized at the beginning of the program, so the initial startup event may be judged only when the program retreats to the background. At present, we will make up a TA when we retreat backstage for the first time* app* Start (the report is a little late, but the event time #event_time is correct and does not affect the subsequent analysis).
# What are the contents of crash events? How to collect crash events?
The client side SDK supports the collection of partial crash logs. You need to turn on the automatic collection of APP Crash after initializing the SDK. The event corresponding to the crash event is named: ta_app_crash.
The situation that triggered the crash event collection:
- Android platform: Uncaught exception in virtual machine
- iOS platform:
- Unix signal anomalies, including: SIGABRT, SIGILL, SIGSEGV, SIGFPE, SIGBUS
- NSException exception
# How to troubleshoot the problem of Android automatic event collection?
Most autocapture events only need to call the enableAutoTrack interface. If you need to collect control click events, or Fragment browsing events, you need to apply the automatic collection plug-in provided by TA, please refer to the chapter of the Android SDK Automatic Collection Guide .
If you use an auto-capture plug-in and have a compilation error, it may be caused by a conflict between our plug-in and some packages. Most of the time, you just need to find the wrong package name prompted in the log and add the following content to the gradle configuration (take com.alipay as an example) to solve it:
thinkingAnalytics {
exclude 'com.alipay'
}
If your project uses MultiDex, you may encounter ClassNotFoundException errors. This situation requires packaging the class that reported the error into the main dex, and to ensure that the code of our SDK is packaged into the main dex, add the following configuration in multiDexKeepProguard:
-keep class cn.thinkingdata.android.** { *; }