mirror of
https://github.com/zhigang1992/react-native-firebase.git
synced 2026-05-06 08:23:35 +08:00
49 lines
3.1 KiB
Markdown
49 lines
3.1 KiB
Markdown
---
|
|
title: Crashlytics in the Firebase Console
|
|
description: Managing the Crashlytics results in your Firebase console.
|
|
next: /database/usage
|
|
previous: /crashlytics/usage
|
|
---
|
|
|
|
# Overview
|
|
|
|
Once you have Crashlytics up and running in your app, you can navigate to Crashlytics in your Firebase Console underneath
|
|
'Quality' and start reviewing the reports as they come in. If this page still tells you to setup, build or run your app
|
|
then you have not correctly setup Crashlytics in your app (see [Usage](/crashlytics/usage)).
|
|
|
|
> Keep in mind when testing out Crashlytics that Crashlytics is [disabled by default in debug mode](crashlytics/usage#crashlytics-in-debug-mode).
|
|
|
|
Upon running the first two examples under [usage](crashlytics/usage), you will be shown a display similar to following image.
|
|
|
|
In this example the [Crash Attributes](crashlytics/usage#crash-attributes) example was ran four times and the [Error Reports](#error-reports) example three times, in addition to several miscellaneous exceptions that have occurred during the write-up.
|
|
|
|
> If you are certain that your app has produced error reports, but none are visible, try restarting your app fully. Crashlytics only uploads reports upon launching the app.
|
|
|
|
## Issues
|
|
|
|
Under issues, Firebase has gathered all the reports from your app and organized them into separate issues, where each
|
|
issue is a unique crash or stack trace in your app. One of the issues visible in the example shown originates from `CrashTest.java`,
|
|
which is the Android module responsible for testing Crashlytics through the `crash` method, throwing an uncaught exception
|
|
to crash the app. Using this method on the same platform will always add reports to the same issue.
|
|
|
|
# Managing issues
|
|
|
|
By clicking on a specific issue, you can view its statistics and all the associated reports in more detail. In this example
|
|
we're viewing the `CrashTest.java` issue.
|
|
|
|
|
|
|
|
Here you're shown the breakdown of this issue by date, device and operating system. On the bottom you can browse specific
|
|
reports and view their specific contents. We have selected the logs part of the report, showing the two custom log messages
|
|
that our example generated. Note that there is a third `Crash Test` log automatically generated by Crashlytics upon using the
|
|
`crash` method. By navigating to data you can view information about the platform where the report was generated and information
|
|
about the associated user. Under keys you can see the custom attributes that we have attached to the report.
|
|
|
|
## Closing issues
|
|
|
|
Note that in the top right there is a button that says 'Close'. After having addressed an issue you can close it, allowing
|
|
you to filter it out in the overview by selecting 'Open' under 'Issue state', when clicking on the 'Filter issues' button.
|
|
This is visible in the first example, where we're displaying only 3 relevant non-fatal events out of the 12 that occurred.
|
|
When the same issue re-occurs, it will automatically open again. By clicking the arrow next to the button we can mute the
|
|
issue, preventing this from happening.
|