Crash Reporting for Android

There’s no such thing as bug-free software. Sorry to disappoint you right out of the gate, but let’s be honest, it would be a shame for all the good folks working hard to make tools helping developers to find and fix those nasty bugs, wouldn’t it? With the help of these tools, the statement, “The app’s not working!” turns into a meaningful error report that lets the developer specifically target the problem. I’ve taken a look at the 3 most well-known tools and will share my findings with you now.

crashreporting

The tools which this thing will be all about are Firebase Crash reporting, Crashlytics and ACRA. Of course, there’s many more (such as for example Hockeyapp, Bugsnag or Apteligent), but I’ll save your scroll-finger some work by limiting myself to three.

And those are the things we’ll take a look at:

– Setup: how fast/easily can you integrate the tool into your app?
– Reports: what do they look like and are the helpful?
– the pros and cons of each tool

Let’s get started!

Setup

For the sake of simplicity, we’ll just assume that there’s an existing Android project into which the various tools can be integrated.

Firebase Crash Reporting

There is a way to integrate this tool manually, but we’ll chose the absolutely easiest and quickest way here:

– log into Android studio on the upper right
– navigate to Tools -> Firebase -> Crash Reporting
– a few button clicks -> done

firebase setup

Now the app will send you reports for unexpected crashes.
Setup time: 1 minute (including short coffee break). Easy peasy.

Crashlytics (Fabric)

Fabric also offers an automated integration method with the help of an Android Studio Plugin, which you need to install first. So the easiest way to integrate Crashlytics is this:

– navigate to Settings -> Plugins -> Browse repositories -> search for ‘Fabric’ -> install
– open the plugin
– click yourself through the fancy user interface and install Crashyltics

fabric setup

The code for the tool’s initialization will be added automatically by the plugin, which means that, also in this case, the app will send you error reports without any additional action on your part.

Setup time: 3 minutes (which is not due to a longer coffee break, but to the plugin being a little laggy)

ACRA

For ACRA, there is no plugin for an automatic installation. But don’t worry, the manual way is also pretty easy:

– add the following to your app’s build.gradle:

compile 'ch.acra:acra:4.9.0'

– give your app the internet permission:

<uses-permission android:name="android.permission.INTERNET"/>

– create an application class in your project and annotate it with:

@ReportsCrashes(
      formUri = "http://www.backendofyourchoice.com/reportpath"
)

– implement the following method in your application class:

@Override
      protected void attachBaseContext(Context base) {
         super.attachBaseContext(base);
         // The following line triggers the initialization of ACRA
         ACRA.init(this);
      }

Attentive readers have, of course, immediately noticed the variable in this process: formUri. This specifies the URL of the server to which the error reports will be sent. Which means that ACRA is by default not linked to an online platform, that will have to be provided by the developers. However, there are many ways to achieve some report visualizations.

For a while, you could send the reports to Google Docs, but due to the huge popularity of this solution (and the resulting traffic), Google politely asked ACRA to bin it. There is an official open source tool called Acralyzer, the hosting for which you would have to provide yourself, though. For my test, I used a cloud-based platform called Splunk MINT (previously Bugsense). The integration works as follows:

– create an account with Splunk MINT
– click on “add app” on the upper left and fill in your information
– copy the API key

In order to make ACRA send its reports to Splunk MINT, you enter the following as your formUri:

@ReportsCrashes(
      formUri = "http://www.bugsense.com/api/acra?api_key=YOUR_API_KEY"
)

Setup time: 5 minutes (when using Splunk MINT as your backend, no coffee break)

Reports

Ok so our app is filled to the brim with crash reporters. We’ll just quickly add a crash-bug, force a few crashes and then we’ll take look at those reports.

Firebase Crash Reporting

First, we log into the firebase console and select the project associated with the app. The menu item ‘Crash-Reporting’ gives us a good overview including the most important metrics.

firebase backend

You can get a detailed description of the individual bugs by selecting one from the list. It gives you all the necessary information such as the app version, the Android version, the device name, the language, etc. There are various filter options available which let you reduce the view to the criteria you need. It’s all very well structured and you’ll find your way no problem.

firebase detail

Crashlytics (Fabric)

Here, you’ll get the reports after logging in to Fabric and selecting your project from the ‘Crashlytics’ menu. After all the UI elements have calmed down a bit …

meme

… you’ll get an overview of all the necessary info just like in firebase.

creashlytics backend

Again, you’ll get a more detailed bug description after selecting one from the list. As opposed to Firebase, not all device info is immediately visible. It’s hidden behind the ‘View all sessions’ button, though. Also here, the volume of data presented is, in any case, more than sufficient.

crashlytics detail

ACRA bzw Splunk MINT

How the reports are presented for ACRA completely depends, of course, on your choice of backend. In the case of Splunk MINT, you can view the reports overview after logging in, selecting your project and navigating to the ‘Errors’ menu.

splunk backend

Even though ACRA sends every little detail about the device to the backend, Splunk MINT only opted to display a few of them in the detail view.

splunk detail

Pros and Cons

Finally, we’ll take a look at some pros and cons of the individual tools.

Pro Firebase Crash Analytics

– it’s free
– really easy setup
– you can use it together with Firebase Analytics in order to get some context for the individual errors (!)
– sends you notification emails for new crashes
– you can tag errors as processed/closed
– keeps expanding and adding highly desirable features
– crash reports appear seconds after crash

Con Firebase Crash Analytics

– Google Play Services must run on the device (that’s a problem especially in the Chinese market)

Pro Crashlytics

– it’s free
– extremely easy setup
– super fancy web UI
– also sends you notification emails for new crashes
– you can search crashes in the web console
– you can also tag errors as processed/close and even add a comment
– Google Play Services are not a dealbreaker

Con Crashlytics

– its future is somewhat uncertain (more on that later)

Pro ACRA

– it’s free and open-source
– includes support for customizable notifications in case of unexpected app crashes
– ample configuration possibilities
– you can use your own backend
– an open source backend implementation exists

Con ACRA

– you need to select (and maybe also implement) your own backend

So which way to go?

As with most things, there is no absolute and universal answer when selecting the best Crash Reporting tool. Which of the three you’ll prefer largely depends on your individual needs. Crashlytics seems a little more mature than Firebase Crash Reporting, but actually, that is likely to benefit Firebase, since Google recently acquired Fabric. The services offered by Fabric are being continued for the moment, but it’s hard to say where the train’s headed. According to Firebase product manager Francis Ma, the plan is to make Crashlytics the core of Firebase’s crash reporting.

If you want to plan with an eye on the future, you might be safer with Firebase Crash Reporting, but that’s pure speculation at this point. If sending data to a third-party cloud service is a problem, ACRA will be your best option, since you are free to decide where to send your information.