Investigate a mobile app crash report

The Crash report of mobile monitoring provides a summary and in-depth details on crashes, including:

• Device and OS breakdown
• App version
• Occurrence count
• Unique users affected
• A timeline of the interactions and events associated with the crash
• In-depth details from a sample of occurrences

View the crash report

To view a crash report:

1. Go to one.newrelic.com > All capabilities > Mobile > (select an app) > Exceptions > Crash analysis.
2. From the Crash list table, select any row.
3. Review the selected crash report's summary and detail information.
4. Optional: Query or share the chart data.
5. Optional: Export to Xcode or resymbolicate your source code for easier debugging.
6. To file a ticket, select any of the options integrated with your system.
7. To close the crash report: At the top of the report, select Mark resolved.
8. To return to the Crash list table: At the top of the report, select Back to crash analysis.

View crash report drill-down details

Use any of New Relic's standard UI functions to drill down into detailed information. The Crash report page includes several additional options.

Crash summary

The crash summary contains aggregated information about all occurrences of this crash:

• Crash identifier: The unique identifier for this crash, which contains information such as exception name, crashing file, line, message, and function
• Crash occurrences chart: A chart showing the number of occurrences of this particular crash over the selected time period since the first time the crash was detected
• Breakdown of crash type: A stacked bar chart showing the breakdown of operating system versions where this crash occurred or devices affected
• Users affected and occurrences: Counts for the number of unique users and number of times the crash occurred

Occurrences count

If the mobile agent has collected more than one occurrence of the crash, you can scroll through the samples.

Event trail

The event trail shows all chronological event types that led up to a crash.

You can sort the event trail chronologically in both directions, though it defaults to showing the oldest event first, usually an App launch. Filter events by event type (i.e., Interaction, Request, or Request Error), reorder events ascending or descending timestamps, and click to expand each event to see more details on what happened. For example, if you want to investigate a Request event, you can expand on the event and look at responseTime and requestUrl.

Details

Each crash sample provides details about the device where the crash occurred, including:

• App version: The application version where the crash occurred

• Device type: The specific device where the crash occurred

• OS version: The operating system version of the device

• RAM used: The amount of memory used by the application at the time of the crash

• Disk free: The amount of free disk space on the device at the time of the crash

• Attributes: Details about attributes related to the crash report which you can collapse or expand for deeper analysis

  If applicable, you can Export crash details to Xcode or resymbolicate your source code for easier debugging.

Stack traces

The stack trace for the thread that generated the crashing exception appears below the crash details. Each frame of the stack shows the library or package name and the method associated with that stack frame.

The agent attempts to detect which frame of the stack contains the programming flaw responsible for the error. If detected, that stack frame appears red.

To view the state of threads other than the crashing thread, select See all threads.

• iOS apps will only show source code method names and line numbers if you have uploaded the dSYM for each build of your application.
• Android apps using ProGuard will have the package and method names de-obfuscated if you have enabled ProGuard map uploading.
• Android native crash reports will only show source filename and relative code offsets.

Android-native crash reporting

Starting with New Relic Android agent version 6.7.0, to help track and diagnose native crashes, reporting, and analysis has been enhanced to include signal violations and other faults that occur at the native code level during runtime.

These enhancements include:

• Native crash reports - signal violations and other crashes reported by the app during runtime, including

  • Signal 4 (Illegal instruction)
  • Signal 6 (Abnormal termination)
  • Signal 7 (Bus error/bad memory access)
  • Signal 8 (Floating-point exception)
  • Signal 11 (Segmentation violation/invalid memory reference)

• Native runtime exceptions The native agent will report any unhandled C++ exceptions thrown by the app during runtime, and report them as handled exceptions. Unhandled exceptions are usually fatal and will crash the application.

• Application Not Responding (ANR) conditions The native agent will detect and report Application Not Responding conditions where an Activity or service thread has been blocked for longer than Android's allowable time, which is 5 seconds for foreground activities, and 5 to 200 seconds for services. ANR conditions will be reported as a handled exception (rather than crashes), since these are not considered fatal conditions.

You can view detailed information about native crashes in New Relic Mobile's Crash analysis UI, or receive crash notifications by email. You can also explore the crash data deeper with New Relic Insights, or integrate with ticketing systems for further investigation.

Configuration

Configuration requires adding an additional dependency in the build.gradle file of the app project(s) that start the new Relic agent:

dependencies {
    implementation 'com.newrelic.agent.android:agent-ndk:1.+'
}

Android native agent artifacts can be found on MavenCentral, and follow semantic versioning conventions. Refer to Android agent release notes for full details on releases and downloads.

Startup

In app code where the New Relic agent is added (usually MainActivity), enable the NativeReporting feature flag prior to starting the agent:

NewRelic.enableFeature(FeatureFlag.NativeReporting);
NewRelic
      .withApplicationToken("<appToken>")
      .start(this.getApplication());

Disable native crash reporting

If you want to use another native crash reporting tool, disable New Relic Mobile's native crash reporting by calling NewRelic.disableFeature{FeatureFlag/NativeReporting) prior to agent initialization. For example:

NewRelic.disableFeature(FeatureFlag.NativeReporting);
NewRelic
      .withApplicationToken("<appToken>")
      .start(this.getApplication());

Debug the native crash reporter

Crash reporting for Android is designed to work with other crash reporting frameworks by chaining the uncaught exception handler if it is already registered.

Any problems that arise during reporting will appear in logcat. Each time New Relic traps a violation, it is logged to DEBUG level. For example, for a segment violation you would see

Signal 11 intercepted: Segmentation violation (invalid memory reference)
Invoking previous handler for signal 11

Native report delivery is deferred until the next app invocation, so you not see crash reports in the New Relic Mobile user interface until the app has been launched again. In the event of a crash, the native agent will generally not have enough time or stability to process the report. Instead, the report data is quickly written to local storage, to be processed the next time the app is launched.

Troubleshooting

Native reports are stored on device as JSON files in /data/data/{app package name}/cache/newrelic/reports. This directory should not contain any reports after the app launch following a crash. As with other agent runtime information, the native agent writes its status to logcat to blend in with agent runtime status. The Android agent’s log tag is com.newrelic.android and can be isolated from other runtime logging by running 'adb logcat | grep "com.newrelic.android" from the shell.