The preview of Crash Analytics 2.0 is available to all users of Flurry Analytics.
Crash Analytics 2.0 in Flurry gives you,in real time, information about crashes, exceptions and errors in your app. This allows you determine the root cause of any issue quickly, keep your app running well and the users of your app happy.
With Flurry Crash Analytics 2.0, you can :
- understand how many devices and sessions have been affected by crashes, Caught Exceptions or logged errors in the past minutes and hours
- compare the health of apps over the last year
- survey the health of collections of apps over the last 24 hours
- review the collection of issues affecting a given app to find the most user-impacting
- investigate the details of instances of a given issue including device details and symbolicated stack traces
- automatically upload dSYM files from xCode using a build phase script
Flurry Crash Analytics provides insight on more than just crashes by including Caught Exceptions and Logged Errors as well. These three types of issues are defined below:
- Crash - An uncaught exception that occurred during the operation of the app that resulted in the app terminating abnormally.
- Caught Exception - An exception that occurred during the operating of the app that was handled by an error handler and reported using a method in the Flurry SDK.
- Logged Error - An error experienced by the code of your app that your code logged using a method in the Flurry SDK. As there was no code execution exception in a Logged Error, there is no stack trace provided.
For details on how to instrument each of these issue types, see the Instrumentation section below.
Real Time Dashboard¶
Similar to the Real Time dashboard located in the Metrics section of Flurry, the Real Time dashboard in Crash Analytics displays data as it comes in to Flurry from your app. There are two time periods that are displayed:
- Minute by minute for last 2 hours
- Hour by hour for last 24 hours
For each of these time periods, there are three charts showing the following metrics:
- Device Impact Rate - The number of devices that experienced an issue in the the period divided by the number of devices that were active in the period.
- Session Impact Rate - The number of sessions that experienced an issue in the the period divided by the number of sessions that occurred in the period.
- Issue Occurrence Count - The number of issues that occurred in the period.
You can filter the data on this dashboard by any of the following attributes:
- App Version
- Device Model
- Device Model Code (e.g. iPhone 6,1)
- Issue Type
- OS Version
- Flurry SDK Version
The Historical Dashboard displays the same metrics as the Real Time dashboard, with two primary differences.
The Historical dashboard:
- provides access to a year of data as opposed to the 1 day on the Real Time dashboard.
- supports a subset of the filters that are supported for Real Time
- App Version
- Issue Type
- OS Version
The App Survey provides a quick look at the performance of collections of apps. The apps displayed here are determined by the selected App Group. Flurry provides various default App Groups such as iOS Apps and Android Apps, but you can create your own App Groups for a customized look in the App Survey or other app-driven dashboards throughout Flurry.
Single App Overview¶
The Single App Overview, as it’s name implies, provides an overview of the issues affecting a single app. The page provides a listing of all the issues that have occurred in the app and metrics that breakdown the types of these issues between Crashes, Caught Exceptions and Logged Errors.
The metrics provided on the Single App Overview provide both an view into the overall health of the app as well as how the impact breaks down by Issue Type.
The metrics are defined as follows:
- Issue Free Devices - the percentage of devices active during the period that did not experience any issue.
- Total Issues - the number of issues during the period
- Crashes - the number of issues of type Crash during the period.
- Crash-Free Devices - the percentage of devices that did not experience a crash during the period. The small number to the right of the percentage is the absolute number of these devices.
- Exceptions - the number of issues of type Handled Exception during the period.
- Exception-Free Devices - the percentage of devices that did not experience a Handled Exception during the period. The small number to the right of the percentage is the absolute number of these devices.
- Errors - the number of issues of type Logged Errors during the period.
- Error-Free Devices - the percentage of devices that did not experience a Logged Error during the period. The small number to the right of the percentage is the absolute number of these devices.
Missing dSYMs / Mapping Files¶
Flurry Crash Analytics supports the automatic upload of dSYMs for iOS and ProGuard Mapping files. When processing the incoming data, if Flurry finds that the correct files are not available for re-symbolicating the Crash or Handled Exception, a banner will appear that states files are missing.
Expanding this banner presents a table indicating the versions for which issues exist that cannot be symbolicated, the number of these and their impact on users. Clicking on a row of this table allows you to browse the non-symbolicated stack traces and understand which files are required for symbolication.
The issues table presents the collection of all the unique issues that have occurred in the period that could be properly symbolicated. Uniqueness is determined by fingerprinting the stack trace for issues that of type Crash or Handled Exception and by the name provided for Logged Errors.
|Status||Displays the current status of the item. The possible values for Status are Open and Resolved. The status can be changed on the detail view for an issue.|
|Issue Number||A unique number given to each issue as it is identified as being unique.|
|Issue Description||For Crashs and Caught Exceptions, this typically includes the module, function and line number where the issue occurred. For Logged Errors, this is the name and description provided to the logging method in the SDK.|
|Issue Type||Identifies the issue as a Crash, Handled Exception or Logged Error.|
|First Seen Version||The first version on which the issue was encountered.|
|First Seen Date||The first date/time the issue was encountered.|
|Last Seen Version||The latest version on which the issue was encountered.|
|Last Seen Date||The latest date/time the issue was encountered.|
|Occurrences||How many times this issue has occurred in the time period.|
|Issue-Free Device Percentage||The percentage of devices active during the period that did not encounter the issue.|
When you click on an item in the Issues table described above, the Issue Details page appears. This page provides you with information related to the specific issue such as:
- Occurrence and Impact metrics
- Device and OS Version breakdowns
- Specific instances of the issue including information about the device and the actual stack trace
- The current state of the issue, Open or Resolved
You can browse the provided instances of the issue using the control above the instance detail header. Clicking directly on one of the numbers will bring up that instance of the issue. Clicking on the arrows will provide access to additional instances.
Resolving an Issue¶
In the upper right section of the page, there is a control that allows you to change the status of the displayed issue. By default, Issues have the status Open. To change an Issue to Resolved, simply select Resolved from the dropdown. The change is recorded immediately.
For iOS, there are two sources for the dSYM files that are needed to support the symbolication of stack traces for crashes and Caught Exceptions. Flurry has different processes depending on whether or not you enable bitcode for your app. If you would like to understand more about these dDYM files, you can read Apple’s documentation here.
When you build your app in xCode, it produces dSYMs specific for that build. To enable easy upload of these files, Flurry Crash Analytics 2.0 has a script that you implement in a Build Phase in xCode which will upload the files when you execute a build. You can download the script and instructions for implementation from Flurry’s Github.
In today’s xCode, bitcode is enabled by default. With bitcode enabled, the debug symbols (contained within dSYM files) needed by Flurry to symbolicate your crashes will not be stored on your mac, but instead on Apple’s servers. These dSYMs must be explicitly downloaded by you from Apple either through iTunes connect or xCode. You can read instructions from Apple on how to do this here under the section titled Viewing and Importing Crashes in the Devices Window.
Flurry provides a plugin for FastLane to allow for automated delivery of the BitCode enabled dSYMs from Apple to Flurry. Instructions for using the FastLane plugin are available in the ReadMe of Flurry’s Github repo for the plugin.
If you choose to manually upload the BitCode dSYMs, instructions for doing so are available in the ReadMe of Flurry’s Github repo for the upload client.
If you use ProGuard to obfuscate your Android code, you need to upload your ProGuard Mapping files to Flurry. Flurry provides a service that can be integrated into your Gradle build process to automatically upload these files. Instructions for using this service are available in the ReadMe of Flurry’s Github repo for the upload client.
Please Note: Proper re-symbolication of Android stack traces requires Flurry Android SDK 6.7.0 or greater.
See further instructions to instrument your Android application for Crash Analytics.
See further instructions to instrument your iOS application for Crash Analytics.
Was this document helpful?