TODD BUNNER: Whether you're tracking down
a weird behavior in a beta version of your app
or chasing a crash flooding the app
store with negative reviews, getting precise real time
information is important.
Firebase Crashlytics is our primary crash reporting
solution for mobile.
It captures your crashes, intelligently analyzes
them, and then groups them into manageable issues.
It also provides insight into the events
that led up to the crash and shows you the downstream effect
on your users.
And it does this all through a lightweight SDK
that won't bloat your app.
It also handles NDK crashes, Pro Guard, and supports Kotlin.
So let's get set up with Crashlytics
and spend less time triaging and troubleshooting
issues and more time doing what we love,
building new app features.
In this episode of Firecasts, we'll
explore Crashlytics on Android.
I've worked on a few mobile apps, and on launch day,
it's always tricky.
Keeping an eye on stability, growth, and revenue
can keep everyone quite busy.
Crashlytics offers a way to get real time alerts about changes
in the stability of your app.
So let's get set up.
Go ahead and follow along in your favorite app.
I'm going to use the Firestore Code Lab app, Friendly Eats,
but the process should be nearly the same in your app.
I've already got my app set up to use Firebase
by creating a project in the Firebase console.
Don't know what I'm talking about?
Check out this video first.
OK, so let's get hacking.
Here I have my Friendly Eats app set up in Android Studio.
First we add the fabric build tool to our project level
build.gradle.
This handles settings, symbol n and a few other bits
during the build process.
To do this, add the Maven Repo and the Fabric Gradle tool
dependency.
Now on our app level build.gradle,
we need to add the Crashlytics SDK dependency.
With just that, crashes will come into our dashboard.
But I think it will be good to test our implementation, too.
I've already added a Crash button to our options list.
Now lets wire it up.
Add the Crashlytics.getinstance.crash
method.
Now we should be able to build and run our app
and finally click on the Crash button.
Now, if we go to the Crashlytics dashboard in Firebase,
we should see the crash immediately.
When I land in the Crashlytics dashboard at the top,
I can filter by version.
Choose to show crashes or nonfatals-- or both--
and select the date range.
Scrolling down, our crash now shows.
And if we click into it, we can get the full stack trace.
If we look at the logs, we can see that there
was a screen view event.
This comes automatically from Firebase Analytics,
but you can log anything you want using our helper methods.
More on that in a minute.
You can also see device specific information
for each session and an aggregate
at the top of the page.
OK, so we've got basic crash reporting working.
But sometimes more information helps
us get to the bottom of what's happening.
Maybe our legacy email auth is causing the issue,
or maybe the crash only happens at a certain level of the game.
Wouldn't it be great if we added more power to our logging?
On Android, use Crashlytics.log to add even more logging.
Crashlytics.log can write logs to a crash report
and do a print line, or just log it to the next crash report.
To avoid slowing down your app, Crashlytics limits
logs to 64 kb.
Crashlytics deletes older log entries
if a session's logs go over that limit.
Custom keys can also be used to help
you get the specific state of your app leading up
to the crash.
You can associate arbitrary key value pairs
with your crash reports and see them in the Firebase console.
There are five methods to set keys.
Each handles different data types.
Resetting a key updates its value.
Finally, we can add a special set of key value pairs
for user identifiers.
To diagnose an issue, it's often helpful to know which
user experienced the issue.
Crashlytics includes a way to anonymously identify
users in your crash reports.
To add user IDs to your crash reports, assign each user
a unique identifier in the form of an ID number token or hash
value.
Now that we know how to get more detail out
of our crash reports, let's talk about nonfatal exceptions.
On Android, that means you can log caught exceptions
in your app's try catch blocks.
All logged exceptions appear as nonfatal issues in the Firebase
console.
The issue summary contains all the state information
you'd normally get from a crash, along with breakdowns
of the Android version and hardware device.
Crashlytics processes exceptions on a dedicated background
thread, so the performance impact to your app is minimal.
To reduce the user's network traffic,
Crashlytics batches logged exceptions together
and sends them the next time the app launches.
As a final bonus for those of you
using Andrea's native development kit,
Crashlytics also supports NDK crash reporting out of the box.
To get that set up, we need to take a few steps.
First add this line to your mainactivity.java,
and disable the automatic invocation of Crashlytics
by going to the Android manifest and editing it
by changing the collection enabled bit to false.
And that's it.
As long as you build with Gradle,
native crash reports will come in,
symbolicated through a symbol upload
tool and our Gradle tool.
Crashlytics offers broader crash coverage
with a real time dashboard and notification
system than our previous crash reporting solution.
It also offers the ability to create custom logs and keys
to collect information and context about the events that
led up to a crash.
And that's Crashlytics for Android.
We've been looking forward to having you be part of Firebase.
If you want to find out more, check out
the documentation or the friendly chat, Android Code
Lab.
Thanks.
[MUSIC PLAYING]