Crash Reporting

Firefox for Android uses a few libraries for crash and exception reporting. This kind of reporting gives Mozilla invaluable insight as to why Firefox for Android crashes or incorrectly behaves. It is one of the key methods we use to improve the product in terms of stability.

This page documents the types of crash reporting, how the various parts interact, and what kind of data is sent back to Mozilla.

Documentation for the specific libraries is included in the Android Components Crash Reporting README.

Glean crash ping

Glean SDK is a Mozilla open source telemetry library, which Firefox for Android uses to collect app telemetry. It can also collect crash counts as a labeled counter with each label corresponding to a specific type of crash (such as native_code_crash, unhandled_exception).

The Glean crash ping format is documented here.

To opt in or out of Glean telemetry reporting, visit the Data collection menu under Settings.


Socorro is a Mozilla open source project for crash statistics. Firefox for Android uses Socorro to track native GeckoView crashes. Crash reports contain a signature, classifications, and a number of improved fields (e.g. OS, product, version) - you can read more about what is sent in these fields in the Socorro report documentation.

These crashes contain hardware information and some app metadata, but no personally identifiable information is visible in the report. A few privacy-sensitive parts are only available to users who have “minidump access”, which is a relatively small number of users with specific rules they must follow.

A sample Firefox for Android crash report can be found here.

A crash report is only sent when the user confirms and submits it through the crash reporter notification or dialog. Crash reports are never automatically sent.


Sentry is an open source crash reporting and aggregation platform. Both the client SDK,, and the server,, are open source.

A crash report is only sent when the user confirms and submits it through the crash reporter notification or dialog. Crash reports are never automatically sent.

High-Level Summary

The server is hosted and maintained by Mozilla. There are no third-parties involved, all crash reports are sent directly from Firefox for Android to the Sentry server hosted by Mozilla.

On the client side Sentry is invisible. There are no parts to interact with. It reports crashes and fatal errors back to Mozilla in the background.

On the server side there is a dashboard that the Firefox for Android team uses to look at incoming crash reports. The dashboard lets us inspect the crash report in detail and for example see where in the application the crash happened, what version of the application was used and what version of Android OS was active. Below is an overview of all the attributes that are part of a crash report.

Sentry Reports

A typical Sentry crash report contains three categories of data: device, application, crash. It also contains some metadata about the crash report:

 "id": "6ae18611d6c649529a5eda0e48f42cb4",
// ...
 "datetime": "2018-03-30T23:55:03.000000Z",
// ...
 "received": 1522454183.0,

To clarify, id is a unique identifier for this crash report, not a unique identifier for the user sending the report. We explicitly disable the ability to uniquely identify users from their crash reports.

Device Information

Sentry collects basic information about the device the application is running on. Both static (device type) and dynamic (memory in use, device orientation).

"contexts": {
    "device": {
        "model":"ONEPLUS A5000",
// ...

Application Information

Sentry collects basic information about the Firefox for Android app.

        "app_name":"Firefox Preview",

Crash Information

Stack trace

Every crash report contains a stack trace, which shows what functions in the Firefox for Android code led to this crash. It includes names of Android framework functions and Firefox for Android functions. Here’s an excerpt of three lines from the stack trace:

  "sentry.interfaces.Exception": {
    "exc_omitted": null,
    "values": [
        "stacktrace": {
          "frames": [
              "function": "main",
              "abs_path": "",
              "module": "",
              "in_app": false,
              "lineno": 801,
              "filename": ""
              "function": "run",
              "abs_path": "",
              "module": "$MethodAndArgsCaller",
              "in_app": false,
              "lineno": 911,
              "filename": ""
              "function": "invoke",
              "abs_path": "",
              "in_app": false,
              "module": "java.lang.reflect.Method",
              "filename": ""
Exception message

The first line of every stack trace in every crash report contains a reason - why did this crash happen. This reason is provided by the developers who wrote the code that decide the app is in an error state. These developers include the Firefox for Android team at Mozilla, the Android framework, the Java programming language, and any libraries Mozilla bundles to develop Firefox for Android.

Java, the Android framework, and Mozilla are diligent about making sure that no personally identifiable information is put in any of these messages. We keep them technical and to the point. We at Mozilla stay on top of our dependencies to ensure they’re not including personally identifiable information as well.

Here’s an example message generated by Java:

java.lang.StringIndexOutOfBoundsException: length=0; regionStart=20; regionLength=20

Example of a Firefox for Android generated message:

java.lang.StringIndexOutOfBoundsException: Cannot create negative-length String
Raw data dump

In the explanations above, some redundant fields and field considered less important were omitted for brevity. To review these omissions, this is an example of the raw data the server receives. This is up-to-date as of March 30, 2018.