Ensuring app quality in Android with the new Firebase Crashlytics SDK

This is the follow-up blog post from my previous article on using Google Analytics for Firebase. While GA allows you to measure and understand user behavior, Crashlytics instead allows you to track and keep a log of all the crashes that have happened on the devices using your app—regardless of whether they choose to report the said crash or not.

If you haven’t read my earlier post on using GA on Android, you can read it here:

If you are working on Firebase as a mobile developer, you might also want to go through a series I wrote earlier on working with Firebase:

Traditional methods for getting user feedback concerning an error required the user to send an error report manually, which was not only avoided by many users, but it also required them to send the report immediately following the crash. And if the device wasn’t connected to an active network at the time of the crash, the users weren’t able to send the report later when they had an active connection.

Crashlytics solves all these issues with relative ease since it handles all these scenarios without the user having to do anything at all.

About Crashlytics

Originally a part of the Fabric SDK provided by Twitter, Crashlytics allows you to automatically track and monitor all the crashes in your app. Think of it as a cloud-based logcat, where you’re able to see all the generated logs on your users’ devices in a single place (if you choose to do so).

For example, this is what a typical Crashlytics dashboard might look like:

As you can see, the current dashboard only shows the most frequent crashes. It also shows the exact line that caused the crash to occur, along with the make and model of the devices on which the crash occurs most frequently.

Now that you know the basics of how Crashlytics can help you as a developer, let’s see how to integrate it with your Android app and customize the functionalities it provides!

Adding Crashlytics to an Android app

In order to add Crashlytics to your app, you first need to integrate it with Firebase. After that, you can start logging crashes discovered in your app.

Connecting your app to Firebase

If you’re working on an app that’s already using Firebase, feel free to skip this step and move on to the next one.

The first is a simple one — set up Firebase in your project. You can find a good tutorial here.

Adding Crashlytics specific dependencies

Once you’ve added the app to Firebase, the next step is adding the dependencies required for Crashlytics to work properly. Typically, you’ll need to add the following dependency to your app’s build.gradle file:

// Add the Fabric plugin.
apply plugin: 'com.google.firebase.crashlytics'

dependencies {
    // ...

    // Add the Firebase Crashlytics dependency.
    implementation 'com.google.firebase:firebase-crashlytics:17.0.0-beta01'
}

Next, add the following lines to your project’s build.gradle file:

buildscript {

    dependencies {
        // ...
        
        // Add the Fabric Crashlytics plugin.
        classpath 'com.google.firebase:firebase-crashlytics-gradle:2.0.0-beta02'

    }
}

Once done, sync your changes with Gradle and let it download the required files.

Log a crash manually and see it appear on Crashlytics dashboard

To check and see if Crashlytics is working as expected, you can try to create an error on purpose (by trying to access a null object, an arithmetic exception, etc.) and see if it appears on the dashboard.

Once the crash has been recorded, you should be able to see it on your dashboard like so:

Here you can see the crash reports for an app of mine. Upon clicking on a particular crash, I can see more detailed insights about what caused the crash, along with the line number for the crash.

However, as you can see in the screenshot above, Crashlytics doesn’t explicitly say the class in which the crash occurred. Instead it replaces it with “?” and randomly generated names like “c.c.a.a.d.d.k.a”. The reason for this discrepancy is the obfuscation of the source code added with ProGuard while creating a release build of the app.

Let’s see how to fix this in the next step!

De-obfuscating the crash reports

In Android, while you build a release variant of your app, Studio will generally apply ProGuard to your app to obfuscate the source code so that upon decompiling it, the business logic isn’t easily understood; thereby protecting your IP.

While it’s good for preventing others from looking at your business logic, it can cause issues with crash reporting, as shown in the screenshots above (in the previous section). To fix this, you can simply add the following config to your app’s proguard-rules.pro file, and it should properly de-obfuscate your error logs for you:

After this, any further crashes should be displayed as normal along with a proper class name and error message.

Customizing the crash reports

While Crashlytics includes some pretty robust crash reporting out-of-the-box, similar to Analytics, it also allows you to customize your crash reports and optionally log the steps leading up to a crash.

For example, in case your app suffered from a non-fatal error and you want to report that in the Crashlytics dashboard, you can do so as follows:

fun downloadFile(url : String){
    
    var result: String? = null
    // make network call and populate result
    
    result?.let{
      // network call successed, result is not null
    }?:run{
        // result is null and the network call failed, report the issue in crashlytics
        FirebaseCrashlytics.getInstance().log("File not downloaded")
    }
  
}

The code above will log a message to Crashlytics, even when the app didn’t face a severe crash. This gives you more context about the way your app is being used.

You can also log a custom non-fatal exception that happened in your app onto the Firebase Console. Here’s a sample code snippet that logs an exception that might happen while uploading a file to the server:

fun uploadFile(uri : Uri){
    try {
        // code to upload the file
    } catch (e: Exception) {
        // logs the exception to Firebase Console
        FirebaseCrashlytics.getInstance().recordException(e)
    }
}

Similar to Analytics, you can also set a userId so your users can get personalized crash reports. A user ID can be set as follows:

Exporting Crash Logs to BigQuery

Firebase additionally allows you to integrate Crashlytics with BigQuery to store and explore all the crashes from your users in detail (if needed).

To integrate BigQuery with Crashlytics, you can navigate to the following URL, select your project, and follow the on-screen instructions:

And that’s it! In a few simple steps, you’re not only able to track all the crashes and error reports that your users are facing, but you can also understand the root cause for the crash; i.e. was it an issue with the device, or the network provider, or something else!

With simple steps like these, you can keep your users happy and your UX seamless by monitoring issues in your apps and fixing them as soon as possible

Thanks for reading! If you enjoyed this story, please click the 👏 button and share it to help others find it! Feel free to leave a comment 💬 below.

Have feedback? Let’s connect on Twitter.