FAQs
Download
Focus Mode
Font Size
Crash-Related
Why is the local crash not reported, and how to troubleshoot it?
1. Confirm that the SDK has been initialized locally. During initialization, set the SDK's debug mode
builder.debugMode to true. Use the logcat -s CrashReport eup command in adb debugging to filter the logs. If you see the following information printed by RUM Pro, it indicates that the SDK has been initialized locally.06-13 11:03:09.597 27513 27513 W eup : rumpro debug mode is enabled. Please disable isDebug when you release. -- Running in debug model for 'isDebug' is enabled. Please disable it when you release.06-13 11:03:09.597 27513 27513 E eup : --------------------------------------------------------------------------------------------06-13 11:03:09.597 27513 27513 W eup : rumpro debug mode will exhibit the following behavior -- The following list shows the behaviour of debug model:06-13 11:03:09.597 27513 27513 W eup : [1] Output detailed rumpro SDK log -- More detailed log of rumpro SDK will be output to logcat;06-13 11:03:09.597 27513 27513 W eup : [2] Every crash will be uploaded immediately -- Every crash caught by rumpro will be uploaded immediately.06-13 11:03:09.597 27513 27513 W eup : [3] Custom logs will be output to Logcat. -- Custom log will be output to logcat.06-13 11:03:09.597 27513 27513 E eup : --------------------------------------------------------------------------------------------
2. Confirm whether exceptions can be properly captured by the SDK. After triggering a crash or ANR issue, if the following log is printed, it indicates that the crash exception can be successfully captured by the SDK.
06-13 11:11:41.777 29271 30104 E eup : #++++++++++Record By rumpro++++++++++#06-13 11:11:41.777 29271 30104 E eup : # You can use rumpro(https://console.tencentcloud.com/monitor/rumpro) to get more Crash Detail!06-13 11:11:41.777 29271 30104 E eup : # PKG NAME: com.tencent.demo.rumprodemo06-13 11:11:41.777 29271 30104 E eup : # App VER: 1.0.006-13 11:11:41.777 29271 30104 E eup : # SDK VER: 4.3.0.30-SNAPSHOT06-13 11:11:41.778 29271 30104 E eup : # LAUNCH TIME: 2023-06-13 11:09:4106-13 11:11:41.778 29271 30104 E eup : # CRASH TYPE: JAVA_CRASH06-13 11:11:41.778 29271 30104 E eup : # CRASH TIME: 2023-06-13 11:11:4106-13 11:11:41.778 29271 30104 E eup : # CRASH PROCESS: com.tencent.demo.rumprodemo06-13 11:11:41.778 29271 30104 D eup : isAppForeground:true06-13 11:11:41.778 29271 30104 E eup : # CRASH FOREGROUND: true06-13 11:11:41.778 29271 30104 E eup : # CRASH THREAD: Thread-906-13 11:11:41.778 29271 30104 E eup : # REPORT ID: cf5fb020-4c42-4cee-8d78-299940bd4d5606-13 11:11:41.779 29271 30104 E eup : # CRASH DEVICE: V2034A UNROOT06-13 11:11:41.780 29271 30104 E eup : # RUNTIME AVAIL RAM:5672812544 ROM:87523766272 SD:8731404697606-13 11:11:41.780 29271 30104 E eup : # RUNTIME TOTAL RAM:8068177920 ROM:116628795392 SD:11641908019206-13 11:11:41.780 29271 30104 E eup : # CRASH STACK:06-13 11:11:41.780 29271 30104 E eup : java.lang.RuntimeException: This Crash create for Test! You can go to rumpro see more detail!06-13 11:11:41.780 29271 30104 E eup : at com.tencent.rumpro.proguard.dz.dq(Unknown Source:16)06-13 11:11:41.780 29271 30104 E eup : at com.tencent.rumpro.library.rumpro.testCrash(Unknown Source:28)06-13 11:11:41.780 29271 30104 E eup : at com.tencent.demo.rumprodemo.MainActivity$2$1.run(MainActivity.java:85)06-13 11:11:41.780 29271 30104 E eup : at java.lang.Thread.run(Thread.java:919)06-13 11:11:41.780 29271 30104 E eup : #++++++++++++++++++++++++++++++++++++++++++#
3. Check whether exceptions can be reported normally. You can search for the
crash upload keyword in the filtered logs mentioned above, which will print logs indicating crash type + whether the report was successful. If the report is successful, you will see a sample print like the following. If unsuccessful, please contact us.06-13 11:25:44.752 1566 1795 I eup : java.lang.RuntimeException, crash upload success!
Cause Analysis of Other Issues:
There might be a slight delay in reporting. If you have confirmed that the log indicating successful reporting has been printed, you can wait a few minutes and refresh the page to check whether it has been reported.
If the SDK fails to capture crash exceptions properly, check whether other logic in your service has registered exception capture functions or signals, or whether other third-party exception capture SDKs are integrated. It is recommended to integrate only one exception capture SDK in your service, as other SDK capture logic may interfere with the SDK's exception capture.
Why is there no data displayed for certain information (such as process information)?
Process Information: Process information will not be reported for Java crashes. For Native crashes or ANR issues, the reporting path for process information is separate from crash reporting. After a crash occurs, the user must restart the App to report process information, which will be automatically associated with the corresponding exception case. If the process information section is not shown, it may be because the user did not restart the App.
Partial On-Site Data for Native Crashes: During a Native crash, if JVM-related on-site data cannot be obtained, the reason may be that the JVM environment is corrupted, preventing the crash handling logic from entering the Java layer for collection.
Other Information: Related to the crash capture processing chain, possibly due to system logic interruption causing incomplete collection of information. For details, please contact us for assistance.
Why are the same crash issues not grouped under the same Issue?
RUM Pro extracts certain stack frames from the crash stack trace as signatures for grouping. The extracted stack signatures are displayed at the top of the Issue Details page. If stack traces that visually appear identical are not grouped under the same Issue, it is due to differences between the stack traces that result in variations in the extracted signatures.
If the extracted stack signature is deemed not reasonable enough, you can contact us for consultation and feedback.
Why does the connected device count fluctuate significantly? Why does the crash rate fluctuate significantly?
The count of connected devices is calculated based on device IDs. Incorrect configuration of device IDs (uniqueId) may lead to abnormal statistics for connected devices. For example, setting identical or fixed values for different devices' IDs is not allowed, as fluctuations in connected device counts may be affected by this.
Fluctuations in crash rate may be influenced by the connected device count. If the connected device count remains stable while the crash rate shows significant fluctuations, the issue should be investigated based on specific business logic.
How to determine the SDK version reported in crash issues?
You can first filter App versions using the criteria to locate an individual reported case for the current App version. In the on-site data of the reported case, you can locate the SDK version number field to identify the version number of the currently integrated SDK.
Why is the reported stack trace not translated?
If the error stack indicates that the stack is untranslated, you can perform the following self-checks first:
Symbol tables are matched using
version number + build number for Java mapping symbol tables, while UUID is used for matching Native so symbol tables.If it is a Native stack, check whether the uploaded Native SO has been stripped. Stripped SO files do not contain symbol tables and cannot be translated. You can use the
file command to check if the SO has been stripped. Locally execute file libxxx.so to print SO-related information. *not stripped* indicates an unstripped SO, while *stripped* indicates a stripped SO.If the issue persists, please refer to the Symbol Table FAQ.
ANR related (Android)
Why are local ANRs not being reported? How to troubleshoot this issue?
Why is some information (such as ANR_INFO and ANR Trace) not displayed?
ANR Information: Some ANR details, such as ANR Trace and ANR_INFO, may fail to be obtained due to vendor-customized ANR handling logic. On certain device models, the system immediately terminates the process upon detecting ANR signals, leaving insufficient time to capture the corresponding ANR information.
Other Information: Related to the crash capture processing chain, possibly due to system logic interruption causing incomplete collection of information. For details, please contact us for consultation and feedback.
Why are identical ANR issues not grouped under the same Issue?
What are the conditions for ANR occurrences?
In Android, the system detects an ANR (Application Not Responding) event occurrence in the following scenarios:
When an application performs time-consuming operations on the main thread, such as network requests or lengthy computations, without timely response to user input events (e.g., clicking the screen or pressing keys), the system considers the application unresponsive.
If an application fails to respond to user input events within 5 seconds, the system considers it unresponsive.
When an application performs time-consuming operations in BroadcastReceiver or Service components without timely completion and release of the wake lock, the system considers the application unresponsive.
How to optimize for ANR; what optimization suggestions are there?
Avoid performing time-consuming operations on the main thread.
Handle time-consuming operations with asynchronous tasks.
Use multithreading to handle time-consuming operations.
Use Handler to handle messages.
Jank-Related
How is the suspension rate calculated?
Suspension rate is calculated per device on a daily basis, including the suspension time when the frame time exceeds 200ms while the application is in the foreground, and the duration the application is in the foreground.
Device suspension rate = Total suspension time of the device in a day (in seconds) / Total foreground duration of the device in a day (in hours). The unit of suspension rate is seconds per hour (s/h).
How is FPS counted?
FPS is aggregated by scenario, currently counting the FPS of actual UI refreshes in the application while excluding data from periods with no UI refresh. The FPS data displayed on the platform undergoes normalization to accommodate different screen refresh rates.
How is the time consumption of stagnant methods calculated?
In stuttering issue monitoring, method execution time is estimated through continuous stack sampling combined with sampling intervals. For example, if a stack is sampled consecutively 6 times with a 52ms interval, its execution time is calculated as 6 × 52 = 312ms.
This estimation method has a margin of error equal to the sampling interval, but the jank duration is accurate, representing the execution time of a UI thread message. The current jank monitoring determines whether the application has experienced jank by tracking the processing time of UI thread messages.
In the stack tree or flame graph, what does a stack with a processing time of 52ms represent?
If a stack's recorded time is 52ms, it indicates the stack was sampled only once during continuous sampling and does not necessarily represent its actual execution time. When a stack is sampled N times (where N > 1), its execution time must be greater than (N-1)*52ms.
Sampling Interval:
Device models for both Android and iOS may have different sampling intervals. You can determine the sampling interval for this specific case by combining the sampling count displayed in the time slice with the calculated sampling duration.
What is critical stack execution time?
Each case contains a stack tree. To aggregate issues, features need to be extracted. Extracting key stacks incurs time consumption, causing stuttering. As shown below is the key stack of a case.
The significance of the maximum time consumption at leaf nodes
The maximum time consumption of leaf nodes refers to the highest time consumption among all leaf nodes in a stack tree. If a stuttering issue exhibits a high maximum leaf node time consumption—especially when approaching the key stack time—it indicates that the leaf node stack is the primary cause of stuttering. Scenarios such as deadlocks, UI threads performing I/O operations, or UI threads accessing databases often result in significantly high maximum time consumption at leaf nodes.
Symbol Table Related
Why does the exception stack prompt appear untranslated?
The main reason the exception stack trace shows untranslated is that the corresponding symbol table has not been uploaded.
1. You can click Symbol table not uploaded,upload now to switch to the Symbol Table Tab and upload the specified symbol table according to the instructions.
2. After confirming the symbol table has been successfully uploaded, click Issue Details and then select manual restoration at the top to perform stack restoration.
Note:
After manually restoring the stack, the exception stack trace changes, which alters the case features generated from it. This will cause the restored case to be aggregated into other issues.
Why file drag-and-drop fails during web upload
Whether it's an so symbol table, dSYM file, or Java mapping file, users must first compress them into a zip file before dragging and dropping for upload. The upload component only supports zip files and does not accept files in other formats.
For mapping files, they must be named mapping.txt, compressed into mapping.txt.zip using zip, and then dragged into the upload area.
For so files, first compress the target so file into a zip archive, such as compressing libnative.so into libnative.so.zip, then drag it into the upload area.
For dSYM files, first compress the target dSYM file into a zip archive, such as compressing RUMPro.dSYM into RUMPro.dSYM.zip, then drag and upload the RUMPro.dSYM.zip file.
Why does the symbol table file status still show as not uploaded when the webpage indicates a successful upload?
There are two possibilities for this situation:
Case 1: The symbol table failed to be uploaded successfully. Refer to Why File Upload or Drag-and-Drop Failed to ensure the symbol table file is properly named and compressed into a zip archive.
Case 2: The symbol table file has been uploaded, but there is a delay in processing. You may need to refresh the page.
Why does the upload prompt indicate success for the mapping file, but the uploaded symbol table file cannot be found?
In this case, you can first try refreshing the page. If the uploaded symbol table still cannot be found after refreshing, or if the symbol table Tab indicates that the file has not been uploaded, it may be due to the mapping file not being properly named.
For mapping files, they must be named mapping.txt, compressed into mapping.txt.zip using zip, and then dragged into the upload area.
The mapping file is identified using
App version number + build number as the Key. Please verify whether the version number and build number are correctly entered.Why is a Java environment required for uploading symbol tables?
The symbol table extraction tool relies on the Java environment. It extracts only essential information, which can significantly reduce the file size required for upload.
The symbol table upload failure prompt indicates a UUID mismatch
The UUID of the symbol table changes with each build. Therefore, only the symbol table file generated from that specific build can restore crash reports uploaded after the same build.
Failure to configure symbol table restoration will not affect exception reporting, but it will impact the ability to restore crash stack traces
Without symbol tables, stack traces cannot be restored to the classes or methods in the code along with source file line numbers, which may impact crash deduplication. However, this does not affect exception reporting.
Do I need to configure symbol tables for each version?
Yes, each App version requires a corresponding symbol table (Java Mapping files, so Symbol files, and Apple C++ dSYM files). The configuration is only effective for the specified version, and duplicate configurations will override existing ones.
Does the Java crash stack lack line number information (e.g., displaying "Unknown Source")?
Add the setting to keep line numbers in the ProGuard configuration, for example:
-keepattributes SourceFile,LineNumberTable
Are symbol tables required for Unity Android projects?
For Unity projects, the Java code generated by the Android project consists of only a few entry classes and does not require ProGuard obfuscation. Therefore, there is no need to configure symbol tables (i.e., mapping information).
For Unity projects, the default Native libraries (such as libmono.so, libunity.so) loaded in the Android project do not have debug symbols. Thus, developers are unable to acquire the corresponding symbol information for configuration.
Note:
If developers have independently developed functional components (.jar or .so) integrated into Unity projects, they need to configure corresponding symbol table information (with the "Development Build" option enabled, the debug version of .so files is located in the development directory. These can be generated using the platform's symbol table tool and uploaded to version control).
Why does the stack remain unreadable after the symbol table has been correctly uploaded?
To resolve this issue: it is recommended to re-upload the symbol table and then click Manual Restore to trigger re-restoration.
If the stack trace remains unreadable after re-uploading the symbol table, it is likely that there is an issue with the symbol table or the captured stack. You can manually deobfuscate using the addresses in the stack offline to verify whether the system-captured stack can be properly deobfuscated.
How to determine whether the uploaded symbol table is valid?
Check whether the source file names and line numbers have been restored.
What does "invalid file" mean; how to handle it?
The uploaded file format is incorrect; the system detected that it is not a symbol table file. The system scanning rule is: traversing .so files in the first-level directory, otherwise considered invalid. It is recommended to upload a single .so file. Future versions will optimize the scanning rules.
Help and Support
Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback