SDK Reporting Strategy
If you create a custom exception, you must report the exception or ANR error that is automatically tracked.
During the test, pay attention to the SDK reporting strategy. If a single device reaches the limit on the same day, it cannot report data.
SDK reporting strategy:
Error type | Reporting strategy |
Java exceptions | After the crash is captured, the system attempts to send the crash immediately. If the crash fails, the system starts to send the crash and passes the traffic limit. For more information, see the following table. |
Native Exception | |
ANR | |
Custom exceptions | Reports Java, Native, or ANR errors that follow |
Startup /Network /H5 Page Analysis | Real-time reporting |
strategy details:
Error Reporting Traffic + Quantity Limit: | Current Default Value |
The maximum number of crash logs that can be retained in the crash log directory mCrashLogsFolderName. If the number of crash log files reaches the limit before a log is generated, the earliest crash log is deleted. Each time a crash log is deleted, the statistics item CrashStatKey.LOG_ABANDONED_FILE and CrashStatKey.LOG_ABANDONED_BUILTIN_FILE are increased by 1. | 15 |
the maximum number of custom logs allowed to remain in the crash log directory mCrashLogsFolderName. If the number of custom log files reaches the limit before a custom log is generated, the earliest custom log is deleted. Each time a custom log entry is deleted, the statistical item CrashStatKey.LOG_ABANDONED_FILE and CrashStatKey.LOG_ABANDONED_CUSTOM_FILE are increased by 1. | 10 |
Obtain the maximum number of logcat rows in a Java crash log | 1500 |
Query the maximum number of logcat rows in native crash logs | 3000 |
Obtain the maximum number of lines in the Logcat log. | 1000 |
Whether to synchronously upload the crash logs generated during the initialization of the main process. When this option is enabled, if the SDK detects that the main process has crashed, the SDK attempts to upload the crash log immediately after the crash log is generated (to prevent stable crashes from being tracked in this scenario). This switch takes effect only in Java and native crashes. Custom logs are invalid. The SDK determines the main process as follows: Package Name is equal to the process name in the /proc/self/cmdline. | true |
Whether to upload logs immediately after they are generated. This switch is valid for logs other than custom logs. When custom logs are generated by logs, specify whether to upload them immediately. | true |
whether to clear all crash statistics when the current version of the app is inconsistent with the last run time version. Versions are determined based on the VersionInfo.mVersion, Subversion, and Package Serial Number VersionInfo.mBuildId. | false |
Whether to use the gz algorithm to compress crash logs after they are generated. After the compression is successful, the original log is deleted. If the compression fails, the original log will be retained. | true |
Whether to use the default algorithm to encrypt crash logs after they are generated. After the encryption is successful, the original log is deleted. If the encryption fails, the original log will be retained. | false |
The maximum number of bytes that can be written to each log when logs are generated. When the specified number of bytes is reached, all remaining bytes are discarded. The total length of the log and the number of discarded bytes are recorded at the end of the log. This parameter is valid for Java, NATIVE, and ANR logs. A value of <= 0 indicates that no limit is imposed. | 1024*1024 |
The maximum number of bytes allowed for a single log when a crash log is uploaded. If the limit is exceeded, the log is not uploaded and deleted directly. At the same time, the CrashStatKey.LOG_LARGE_FILE of the statistical item is increased by 1. It is valid for all types of logs. If it is a value of <= 0, it indicates no restriction. | 800*1024 |
The maximum number of bytes that can be used to upload logs within 24 hours. If the upload time is exceeded, logs are not uploaded and are retained on the disk. After 24 hours, logs are uploaded again when the upload operation is called. If it is a value of < 0, it indicates no limit. Each time you try to upload a finding that reaches this limit, the statistic CrashStatKey.LOG_UPLOAD_LIMIT and CrashStatKey.LOG_UPLOAD_BYTES_LIMIT are incremented by 1. | 1.5*1024*1024 |
The maximum number of crash logs to upload per 24 hours. Each time you try to upload a finding that reaches this limit, the statistic CrashStatKey.LOG_UPLOAD_LIMIT and CrashStatKey.LOG_UPLOAD_BUILTIN_LIMIT are incremented by 1. It was renamed from mMaxUploadCrashLogCountPerDay version 3.0.0. | 25 |
The maximum number of custom log entries that can be uploaded in each 24 hours. Each time you try to upload a finding that reaches this limit, the statistic CrashStatKey.LOG_UPLOAD_LIMIT and CrashStatKey.LOG_UPLOAD_CUSTOM_LIMIT are incremented by 1. | 20 |
The maximum number of logs of each custom type that can be generated per 24 hours. The number of custom log entries of different types is counted separately. | 6 |
The maximum number of ANR logs that can be generated by each process. | 3 |
No automatic restart after a crash log is generated | true |
Whether after the SDK handles Java exceptions and generates Java crash logs, the exception information is reported to other people (systems) before the SDK initializes the UncaughtExceptionHandler. | true |
After the SDK has processed native crash signals and generated native crash logs, the system notifies the system of the signal processing function that is registered before the SDK is initialized. | false |
The interval at which information such as the current CPU utilization is automatically updated. Unit: seconds. | 50 |