Firebase Android Series: Crashlytics
Welcome to another article of Firebase Android Series. Here, we are going to learn how to build an Android app using Firebase from scratch.
This is the third article of Firebase Android Series. We put the focus on learning how to use Firebase to enhance an existing feature on your application or adding new ones.
The module that we are going to deal with this time is Firebase Crashlytics.
Firebase Crashlytics is a lightweight, realtime crash reporter that helps you track, prioritise, and fix stability issues to improve your app quality. Crashlytics saves you troubleshooting time by intelligently grouping crashes and highlighting the circumstances that lead up to them.
Keep track of the bugs, crashes and bad smells of our application is not always an easy task. Reproducing an error from your production code is not a piece of cake. Any factor that you have not previously predicted can make your app crash, in the same way that a different density screen can change everything.
Firebase Crashlytics allow us to keep track of all these problems in an easy and friendly way. Finding out if a particular crash is impacting a lot of users, getting alerts when an issue suddenly increases in severity or figuring out which lines of code are causing crashes is priceless information. Firebase Crashlytics collects a lot of information from the user when a crash appears, such as the device characteristics, the battery level, the screen rotation, network connection and many more useful values.
Continuing with this articles series, we are going to add Firebase Crashlytics to our chat application to keep track of any future crash. Let’s do this!
Configuring the project
To start configuring Firebase Crashlytics in our application we just need to go to the Crashlytics tab in our Firebase console and click on Set Up Crashlytics.
Now that we have enabled Crashlytics in the Firebase console we should install the SDK in our project. First we need to include the next lines in our project-level build.gradle file:
Next step should be add the next dependencies in our app-level build.gradle file:
With this basic setup Crashlytics will automatically starts to work listening and collecting crash reports.
You can test your implementation using Crashlytics.getInstance().crash() to cause a crash in your application. The crash will appear in your Firebase console like this:
There are a few tabs in the Session summary of our error trace:
- StackTrace : Shows the error trace in your application code.
- Keys : Custom attributes added to the crash trace by the developer.
- Logs: Application logs. Such as the whole navigation flow of the user before the crash.
- Data: General data about the device and the operating system.
Enabling Crashlytics on demand
There will be some cases where we will want to enable/disabled Crashlytics. Depending of the privacy policy of our application, we would need to disable Crashlytics for the users who doesn’t accept our terms and conditions and doesn’t want to share their information with us.
To achieve this, we will need to disable the automatic initialization of Crashlytics adding the next line to our manifest:
<meta-data android:name="firebase_crashlytics_collection_enabled" android:value="false" />Next step will be enable Firebase Crashlytics on demand in our Application instance:
Customizing Crashlytics reports
Crashlytics automatically starts collecting crash reports as soon as we add it to the application. However we can customise our setup by adding opt-in reporting, logs, keys, and even tracking non-fatal errors. Let’s check the different possibilities.
Tracking non-fatal errors
We can track non-fatal errors using Crashlytics.logException(error).
This kind of crashes will appear on the Firebase Console tagged as non-fatal issues. The issue summary contains all the state information you normally get from crashes, along with breakdowns by Android version and hardware device.
Identifying our users
To diagnose an issue, it’s quite useful to know which of our users experienced the given crash. Crashlytics includes a way to anonymously identify users in our crash reports using Crashlytics.setUSerIdentifier(String identifier).
The identifier must be determined by us. This could be the Firebase authentication user ID, a token or a hashed value.
Adding custom keys and logs
We can include custom keys to our crashes. Custom keys help us get the specific state of your app leading up to a crash. There are five methods to add custom keys to our events, one for each data type:
Together with the custom keys. We can include custom logs to our crashes, allowing us to add more context for the events leading up to a crash. Crashlytics associates the custom logs with our crash data and makes them visible in the Firebase console.
This custom parameters will be shown in the Firebase Console at the Logs and Keys tabs:
Adding a UncaughtExceptionHandler for extra information
The information provided by Crashlytics it’s rich on it’s own, but it might be insufficient for bigger applications where we may want to know some additional details like the available/total heap memory of the phone or the activity stack.
For this cases we can add an UncaughtExceptionHadnler to our application. This Handler is invoked when a Thread abruptly terminates due to an uncaught exception. Using this we can add custom parameters to the uncaught exceptions to show them in our Firebase Console.
We must set the Handler after initialising Crashlytics in our Application class:
Github Sample
This series on the same sample project: Building a chat application using Firebase and Kotlin. You will find each one of the different articles code in individual branches of the project.
