Crash Analytics

Crash Analytics in Flurry gives you real-time information about app crashes, exceptions and errors. Quickly determine the root cause of any issue, keep your app running and improve user satisfaction.

Flurry Crash Analytics

  • Understand how many devices and sessions have been affected by crashes, caught exceptions, or logged errors

  • Compare the health of apps over the last year

  • Survey the health of apps over the last 24 hours

  • Review issues affecting a given app to find the most user-impacting issue

  • Investigate the details of instances of a given issue including device details and symbolicated stack traces

  • Automatically upload dSYM files from Xcode for iOS projects or mapping files for Android projects using build phase scripts.

Bug Issue Types

Flurry Crash Analytics provides insight on crashes, caught exceptions and logged errors. These three bug 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, refer to Crash Analytics for Android or Crash Analytics for iOS.

Real-time Dashboard

The Real-time Dashboard displays crash rates and issue occurrence counts by the minute for the last two hours and by the hour for the last 24 hours as it comes into Flurry from your app(s).

Note

The dashboard refreshes every fifteen seconds.

This refresh is shown as a blue line across the top of the screen. The dashboard uses the following metrics:

  • Device Crash Rate - number of devices that experienced an issue for the the last two hour period or for the last 24 hour period divided by the number of devices that were active in that period.

  • Session Crash Rate - number of sessions that experienced an issue for the last two hour period or for the last 24 hour period divided by the number of sessions that occurred in that period.

  • Issue Occurrence Count - number of issues that occurred in the last two hour period or for the last 24 hour period.

https://s.yimg.com/oo/cms/products/flurry-docs/zh_TW/_images/Crash-Analytics_Real-Time-Dashboard_0c6622233.png

Want more detailed information? Select what apps to monitor and filter the crash data.

Filter by:

  • App Version

  • Country

  • Device Model

  • Device Model Code (e.g., iPhone 6,1)

  • Issue Type

  • OS Version

  • Flurry SDK Version

There are three more dashboards available in the crash analytics toolbox. Select ‘Crash Tools’ on the right hand side of the screen or the crash icon on the left hand navigation menu to access dashboards with historical data.

Crash Tools

There are three more dashboards in the Crash Tool box: Historical Crash Dashboard, App Survey Dashboard, and Single App Overview.

Historical Dashboard

The Historical Dashboard like the Real-time Dashboard reports crash rates and issue occurrence counts, but with two primary differences.

The Historical dashboard:

  • provides access to a year of data as opposed to day on the Real-time Dashboard.

  • supports a subset of the filters that are supported on the Real-time Dashboard. They are:

    • App Version

    • Country

    • Issue Type

    • OS Version

https://s.yimg.com/oo/cms/products/flurry-docs/zh_TW/_images/Crash-Analytics_Historical_72a31ed11.png

App Survey Dashboard

The App Survey Dashboard provides a quick look at the health of all or a select group of apps. Although Flurry provides default App Groups, such as iOS and Android App Groups, Flurry also allows for the creation of custom App Groups.

https://s.yimg.com/oo/cms/products/flurry-docs/zh_TW/_images/Crash-Analytics_App-Survey-Dashboard_73f747514.png

Single App Overview Dashboard

The Single App Overview Dashboard, provides a view of the overall health of a selected app as well as a listing of all the issues that have occurred in the app.

https://s.yimg.com/oo/cms/products/flurry-docs/zh_TW/_images/Crash-Analytics_Single-App-Overview_3b547ac4a.png

The dashboard tracks and displays the number of issue free devices, total issues and then breaks those issues down further by crash, caught exception and logged error issue types.

  • 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.

https://s.yimg.com/oo/cms/products/flurry-docs/zh_TW/_images/Crash-Analytics_Missing-dSYMs_6b1b3dd45.png

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.

Below the overview metrics is a list of unique issues that have occurred in the specified time period. The stack trace is fingerprinted in order to group similar crashes, caught exceptions, and logged errors together. Within the list is each issue’s status, type, description, when it was first and last detected, the number of times it occurred, and the percentage of devices active during the specified time period that did not encounter this issue.

Column

Description

Status

Displays the current status of the item. The possible values for Status are Open and Closed. 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 crashes and caught exceptions, this typically includes the module, function and line number where the issues that occurred are listed. For logged error issues, the name and description are provided to the logging method in the SDK.

Issue Type

Identifies the issue as a crash, caught exception, or logged error.

First Seen Version

The first version in which the issue was encountered.

First Seen Date

The date and time the issue was encountered.

Last Seen Version

The latest version in which the issue was detected.

Last Seen Date

The latest date and time the issue was detected.

Occurrences

The number of times this issue has occurred in the specified time period.

Issue-Free Device Percentage

The percentage of devices active during the period that did not encounter the issue.

Issue Details

Click on an issue in the list to check out more details about that issue. Issue details include:

  • Total Issues and Issue-Free Devices Percentage 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 Closed

https://s.yimg.com/oo/cms/products/flurry-docs/zh_TW/_images/Crash-Analytics_Issue-Details_8e2bd28d5.png

Browsing Instances

Browse the provided instances of any issues by clicking through the pagination tool above the instance detail header. Click directly on one of the numbers to display that instance of the issue. Clicking on the arrows will provide access to additional instances.

https://s.yimg.com/oo/cms/products/flurry-docs/zh_TW/_images/Crash-Analytics_Browsing-Instances_4b1ac8285.png

Closing an Issue

In the upper-right section of the page, there is a dropdown that allows you to change the status of the displayed issue. By default, an issue’s status is set to Open. To close an issue, simply select Closed from the dropdown. The change is recorded immediately.

https://s.yimg.com/oo/cms/products/flurry-docs/zh_TW/_images/Crash-Analytics_Resolving-an-Issue_9fc756c9c.png

iOS Symbolication

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 enabling bitcode is required for an app.

Xcode dSYMs

When you build your app in Xcode, it produces dSYMs specific for that build. To enable easy upload of these files, Flurry Crash Analytics has a script that integrates into a build phase in Xcode to facilitate dSYM uploads. Download the script and instructions for implementation.

bitcode dSYMs

Bitcode is typically enabled by default. With bitcode enabled, the debug symbols (contained within dSYM files) needed by Flurry to symbolicate app crashes will not be stored on the developers’ machine, but instead on Apple’s servers. These dSYMs must be explicitly downloaded from Apple either through iTunes Connect or Xcode. Read instructions from Apple on how to do this here under the section titled Download debug symbols.

  • fastlane Plugin

    • 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 the Github repo for the plugin.

  • To manually upload the BitCode dSYMs, the instructions for doing so are available in the ReadMe of the Github repo for the upload client.

  • Add the Mapping Files directly by clicking the ‘Add Mapping Files’ button on the Single App Overview Dashboard and following the displayed instructions.

Android Symbolication

If ProGuard is being used to obfuscate Android code, ProGuard Mapping files must be uploaded to Flurry. Flurry provides a service that can be integrated into the Gradle build process to automatically upload these files. Instructions for using this service are available in the ReadMe of the Github repo for the upload client.

Refer to further instructions to instrument your Android application for Crash Analytics.

Refer to further instructions to instrument your iOS application for Crash Analytics.