Understanding how to reproduce crashes with Firebase Crashlytics Logs

Hunt those bugs faster — Enhancing crash analysis

Typical android crash stacktrace

Today I discovered something very very useful. I’m not sure if I missed some Android Developers blogpost or tweet from firebase, google, etc., but the feature I’m going to show you is awesome.

Long story short, it’s all about getting user navigation trace when an app was force closed because of a FATAL EXCEPTION(aka. CRASH).

Great news to all Mobile Developers! Specially #android-dev

Firebase Crashlytics is now allowing you to see all the screens the user went through right before a crash happened.

Detailed log of where the user navigation went before the crash

This has a bunch of useful information:

• You can see the step number (#) from beginning to the end (crash)
• The timestamp with seconds!
• The class name in your code that represents a particular screen

How to see this information on the Firebase Console (QA)

1. Open your project from the Console.
2. Select Crashlytics on the left panel (Stability Category)
3. On the bottom half of the screen you’ll see the list of issues. Click on one of the issues, and open the detail.

4. You’ll be presented with STACK TRACE tab opened. Switch to LOGS tab.

5. Click on the black arrow near every screen_view Log entry to enlarge and see which screen is that. Done!

Now you can easily catch the bug!

How to make this work in code? (DEVELOPER)

As I understand, you’ll need to have the latest Firebase Analytics and Crashlytics in your app. That’s all you need to do. After you integrate these two SDKs in the project, analytics automatically collected screen_views are reported, again, automatically to Crashlytics.

Here’s a minimum Android project configuration:

Project/build.gradle

task wrapper(type: org.gradle.api.tasks.wrapper.Wrapper) {
  gradleVersion = '4.1'
}

buildscript {
  repositories {
    maven { url 'https://maven.fabric.io/public' }
    google()
  }
  dependencies {
    classpath 'com.android.tools.build:gradle:3.0.1'
    classpath 'com.google.gms:google-services:3.1.2'
    classpath 'io.fabric.tools:gradle:1.25.1'
  }
}

app/build.gradle:

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

android {

  compileSdkVersion 27
  buildToolsVersion '27.0.3'

  defaultConfig {
    applicationId "com.your.app"
    versionCode 1
    versionName "1"
    minSdkVersion 16
    targetSdkVersion 27
  }
}

dependencies {
  compile 'com.google.firebase:firebase-core:11.8.0'

  compile('com.crashlytics.sdk.android:crashlytics:2.9.1@aar') {
    transitive = true
  }
}

apply plugin: 'com.google.gms.google-services'

IMPORTANT! Use the latest versions. Otherwise you may not see those logs. I know for sure that when Firebase Crashlytics was first announced there was no such feature. And when I updated the versions, I started seeing those logs.

Enhance logs even more

I haven’t tried, but you may also have the ability to track user events, not only screen_views. With this you can have the full story. Just imagine: SplashScreen -> Opened 3rd element from main grid -> DetailScreen -> Rotate event -> Popup shown -> Click on rate me -> CRASH.

UPDATE #1 - Fragments:

In order to make Fragments appear in those Logs, add this line to your BaseFragment#onResume() for example.

firebaseAnalytics.setCurrentScreen(activity, this.getClass().getSimpleName(), this.getClass().getSimpleName());

How this was solved before

Previously I had to implement some homemade solution to this problem. So I had a static array of strings in Application. Then the BaseActivity was adding some lifecycle events to that array. And all this was reported to Crashlytics via log call. And the result is this:

Pretty ugly, huh?

Now, there’re more sophisticated solutions like this using Model View Intent architecture to solve problem. But now no need to change your architecture or implement custom solution.

Firebase is awesome!