If your plan includes crash reporting, crashes will automatically be reported to and viewable from the crashes page of your Instabug dashboard.
You'll also be able to see the trends covering the previous 7 days for percentage of crash-free sessions (sessions that ran and concluded without any fatal errors), total number of crashes, total number of unique affected users, and total number of non-fatal errors. An email will be sent to you if there is sharp decline in the crash-free sessions percentage.
By default, if Crash Reporting is enabled, Instabug captures any ANR that occurs within your app, along with the stack trace of the crash.
You can disable/enable ANR reporting using the following API:
You can manually report your own exceptions or errors in case you already handle them in your code.
To report exceptions manually, use the following method. Both errors and exceptions can be passed to this method.
CrashReporting.reportException(new NullPointerException("Test issue"));
Here is another example.
CrashReporting.reportException(new NullPointerException("Test issue"), "Exception identifier");
CrashReporting.reportException(NullPointerException("Test issue"), "Exception identifier")
In the events that you're using a C++/NDK library or have code that runs at C++ level, the Instabug SDK will automatically detect and capture these low level crashes.
In order to start capturing NDK crashes, you'll need to add the below dependency to your app level gradle. Once it's added and the gradle is synced, NDK crashes will automatically be captured after the SDK is initialized and NDK crash reporting is enabled.
NDK crash reporting is disabled by default if the NDK dependency is added, however it can be enabled using the below method.
Since native code is always obfuscated, you'll need to follow the instructions mentioned in the deobfuscation page in order to make the stack traces more readable.
This section contains a list of all the crashes that have been reported by your application. The title of each crash is usually the most significant line in the stack trace.
Next to each crash in the list, you can find the following details, all of which can be used to sort the crashes:
- Severity: Blue dashes that show the seriousness of this crash from low (one dash), moderate (two dashes), high (three dashes), and critical (four dashes) by taking into consideration several factors, including the percentage of affected users, the number of crashed sessions, and app versions impacted by that crash. When a crash has high severity, an email notification will be sent to your email regarding the crash in question since these crashes have the highest impact on your users.
- Occurrences: The number of times this crash has occurred.
- Users: The number of users affected by this crash.
- Min Version: The lowest app version number affected by this crash.
- Max Version: The highest app version number affected by this crash.
- Last Occurred: When the latest occurrence of this crash happened.
You can then filter for crashes that match any of the following criteria:
- App Version
- User Attributes
Updated 12 days ago