[MUSIC PLAYING]
DOUG STEVENSON: Hey, thanks for tuning into this Firecast.
My name is Doug Stevenson, and I'll
show you how you can get started monitoring
crashes in your Android app with Firebase Crash Reporting.
Imagine you've spent a lot of time
developing and testing your Android app
and you've just published it the Play Store for everyone to use.
Now obviously, you want your users
to have the best possible experience with your app.
So if there's a bug that causes problems in it,
you need to know that as soon as possible so you can fix it.
To help with this, you can integrate the Firebase Crash
Reporting SDK with a single line of configuration
before you publish.
If you haven't integrated any other Firebase
features in your app yet, watch this other video first
to get started.
Then you can follow along here to use Firebase Crash
Reporting.
I already have an app that's using Firebase,
so I'll integrate crash reporting into that.
I'm going to open my apps build dock gradle
and find the project dependencies block.
Then I'll add the dependency for Firebase Crash Reporting.
The latest version at the time of this recording is 10.0.1.
You should find and use the latest version.
Then I'll sync my project.
And that's it.
Adding the dependency is all you have
to do if you want to record when your app crashes.
There are no additional lines of code it write.
It just works.
Whenever an exception is thrown that crashes your app
you receive that exception with its full stack
trace in the Firebase console.
To improve on that there are some additional things
you can do with a few lines of code
using the Firebase Crash Reporting API.
For example, you can log messages
that will appear in a crash report
so you can get some more context into what was happening just
before the crash.
And you can report exceptions that you catch if you
don't know how to handle them.
These will show up as non-fatal reports in the console.
Typically you don't need to report caught exceptions
but it can be useful for diagnosing
rare or unexpected problems.
I'll add some of these calls right now.
First, I'll add a line of code to log a message
that I know will happen just before I report an exception.
Then I'll report a fake exception
that I'll create on my own.
It works the same as if I had caught the exception
inside a tray catch.
Now, I'll build and launch the app and examine the log file.
If I want to see the report for this
I'll load up Firebase console for my app
and select Crash Reporting on the left.
You can see that the console for my app
now shows my exception as a non-fatal error that
didn't crash the app.
If I click into it, I can see details about the device.
In this case, we see it's from my emulator.
The full stack trace is also there, in addition to
the message I logged.
After I fix the problem, I can close this issue with the Close
button so it won't show again.
When a new crash is discovered by Firebase Crash Reporting,
I'll also receive an email notification.
This email gives me some basic details
about the crash and a button to click
to view it in the console.
It should take less than a minute for a report
to show up in the console after it's sent.
When you're trying this yourself be
sure to have a good network connection.
And also try launching the application again
to make sure any unsent reports have a chance
to make it to the console.
A new app like mine doesn't have very many interesting crashes
to view, but you can use the Firebase demo app to view
much more interesting data.
You can get read-only access to that project
by using the link in the description below.
The demo app is called Flooded by Lab Pixies,
which is a game that you can download from the Play Store.
Let's see what crash reports look like for that app
right now.
This project has both an Android app and an iOS app
associated with it.
And I'm going to choose to view the crashes for the Android
version.
Here we can see the recent history of crashes
with details in the table below, sorted by the number of times
each has occurred if I click one,
it will show me the stack trace.
And if I View Details, it will show me some statistics
about this particular error.
Notice that you can view each and every occurrence
of this crash by clicking the arrows.
This entire collection of crashes is called an issue.
And an issue is formed based on crashes
that are similar to each other.
They all represent the same error,
but the stack trace and device details
may be slightly different from each other.
For an individual crash you can see detailed information
about the device at the time of the crash.
In this particular error, the most helpful part
of the stack trace happens to be hidden.
So I'm going to expand that.
Here you can see that the problem
starts in the extra steps activity
in its onResume method.
If I scroll down further, I can see
a log of what happened just before the crash.
Here, there are a bunch of log items
that were automatically created from Firebase Analytics events
at the time they occurred.
These events are logged automatically.
You don't have to write any code to make this happen.
And that's a basic tour of Firebase Crush Reporting.
But there's a few more things you
need to know before you publish your app to the Play Store.
First, be sure to separate your development environment
from your production environment.
The usual way to do that is to create a whole new Firebase
project for each type of build.
That way any crashes that occur while developing your app
will remain separate from those that happened to your users
in production.
You can read this blog post to get more information
about that.
Second, if you're using ProGuard to obfuscate and shrink
your code, you'll need to upload the mappings file
generated for the build that you published to the store.
You can either upload it to the console
or use a gradle plug-in to run a test that performs the upload.
Be sure to read the documentation about that
because you won't be able to read
your stack traces without uploading the correct mapping
file.
If you have any questions about Firebase Crash Reporting,
reach out to us on Twitter with the hashtag #askFirebase or any
of the Firebase support channels.
My name is Doug Stevenson.
Thanks for watching and be sure to squash all those bugs.
Thanks for watching our video.
Check out some more here and don't
forget to subscribe to the Firebase YouTube channel.
[MUSIC PLAYING]