Getting Started with Firebase Crashlytics on Android

Some form of crash reporting in any app doesn’t only help. It’s essential. Not knowing when and where crashes occur in your app by your users can be very destructive. It can lead to uninstalls, bad reviews, and you’re not going to get much success out of that.

So what does a crash reporting service need to do? Well most importantly, it needs to alert you when crashes happen. It should pinpoint the exact line of code where your crash happened so you know how to fix it.

Most crash reporting services offer these two main features. Firebase Crashlytics on the other hand, goes many steps further. In addition to these, it also organises these crashes in a dashboard you can analyse to see the progression of crashes that go on with each new version, per se. Well, here’s the list of what Crashlytics does over other crash reporting services.

Some Major Benefits of Crashlytics

Features a real-time dashboard and alerts to keep you aware of any issues as soon as they happen
Shows crashes ranked by overall impact to users to help you prioritise which bugs need debugging first
For errors that are harder to reproduce, with the help of logs and key value pairs, you can add context to each stack trace and see what was happening before the crash

On top of all this, it’s ridiculously easy to set up in your app. All you have to do is add the dependencies and everything else is done for you, enabling crash reports to start being delivered.

Adding the Crashlytics SDK to your App

Add the Crashlytics repositories and dependency to your project-level build.gradle file.

buildscript {
    repositories {
        // ...
        maven {
           url 'https://maven.fabric.io/public'
        }
    }
    dependencies {
        // ...
        classpath 'io.fabric.tools:gradle:1.25.1'
    }
}

allprojects {
    // ...
    repositories {
       // ...
       maven {
           url 'https://maven.google.com/'
       }
    }
}

2. Add the Crashlytics dependencies to your app-level build.gradle file.

apply plugin: 'com.android.application'
apply plugin: 'io.fabric'

dependencies {
    // ...
    compile('com.crashlytics.sdk.android:crashlytics:2.9.0@aar') {
       transitive = true
    }
    compile 'com.google.firebase:firebase-core:11.8.0'
}

Once you’ve done this, congratulations! You’ll now be seeing crash reports on the Firebase Console.

Testing by Forcing a Crash

Maybe you’re not convinced that it’s working yet, which is a good mindset to have. Everything must be tested. Fortunately for us, we can force a crash with one simple line of code.

Crashlytics.getInstance().crash();

When you force a crash, reopen your app after causing the crash to make sure that Crashlytics sends the crash report. You should be able to see the report in the Firebase Console within five minutes.

Customising Crash Reports

You can customise your reports to do better suit privacy-minded users, to let you know the state of the app before it crashed, and quite a few more.

Enabling Opt-in Reporting

If you want to give users control whether they want their crash reports sent to you, you can enable opt-in reporting instead.

1. Disable automatic collection with a meta-data tag in your AndroidManifest.xml file.

<meta-data android:name="firebase_crashlytics_collection_enabled" android:value="false" />

2. When a user has agreed to have crash reports sent (by an alert dialog you’ve made or whatnot), initialise crashlytics within the activity (whatever activity you’re already on is fine).

Fabric.with(this, new Crashlytics());

*Note: You can’t stop Crashlytics reporting once you’ve initialized it in an app session. To opt-out of reporting after you’ve initialized Crashlytics, users have to restart your app.

Adding Custom Logs

To let yourself know what’s going on before a crash happened, you can add custom logs to your app which Crashlytics will associate with the leading crash report.

Crashlytics.log(msg);

*Note: To avoid slowing down your app, Crashlytics limits logs to 64kB. Crashlytics deletes older log entries if a session’s logs go over that limit.

Add Custom Keys

On top of logs, you can add key-value pairs to give you more context of what happened before a crash. These differ from logs in that a specific key can only hold one value, so say, if you call setString with the key “name” and give it a value of “Monty”, then you call setString with the same key “name”, but give it a different value of “Sponge”, the new value will override the older value and you’ll see “Sponge” in your crash report, but you won’t see “Monty”.

Crashlytics.setString(String key, String value);

*Note: Crashlytics supports a maximum of 64 key/value pairs. Once you reach this threshold, additional values are not saved. Each key/value pair can be up to 1 kB in size.

Adding User IDs

Crashes could be caused by the data held by certain users. Crashlytics includes a way to anonymously identify a user in your crash report.

To include user IDs in your crash report, you’ll have to assign a unique identifier to each user in the form of an ID, number, token, or hashed value.

void Crashlytics.setUserIdentifier(String identifier);

If you need to clear a user identifier after it’s been previously set, just reset the user identifier to a blank string.

Logging Non-fatal Exceptions

Not all bugs can leave your app crashing, but they can still leave your app malfunctioning pretty badly. Crashlytics won’t know when this happens though, so you have to send these reports to Crashlytics manually.

In addition non-fatal, you can prevent your app from crashing from fatal bugs with a try-catch statement and send the crash report after catching the bug while handling the error gracefully in your app.

try {
    methodThatThrows();
} catch (Exception e) {
    Crashlytics.logException(e);
    // handle your exception here
}

try {
    methodThatThrows();
} catch (Exception e) {
    Crashlytics.logException(e);
    // handle your exception here
}

All logged exceptions will appear as non-fatal issues in the Firebase Console.

*Note: Crashlytics only stores the most recent 8 exceptions in a given app session. If your app throws more than 8 exceptions in a session, older exceptions are lost.

I believe it’s good practice to anticipate where fatal and non-fatal errors can happen. Saving your app from malfunctioning could just determine its success. Just because it’s easy to setup the primary functionality doesn’t mean you should stop there by any means.

Eric Decanini

An Android Developer who makes programming memes on TikTok