Getting Started with Firebase Crash Reporting for Android – Firecasts

Getting Started with Firebase Crash Reporting for Android – Firecasts

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]

12 thoughts on “Getting Started with Firebase Crash Reporting for Android – Firecasts

  1. How does it compare to Crashlytics?
    I'm trying to decide if I should switch to Firebase Crash reporting from the Crashlytics.

  2. Hi, how I can set up sending reports for only one email. With Firebase work a many people, reports send for all of them. Thank!

  3. I mad a crash in my Android app but recevied a mail saying i got a crash in my app.Do i get the mail only after publishing my app to google play store?

  4. Why do you say "codeless" and then tell us we have to put in a bunch of code to make apps do a lot of things that most people are going to want their apps to do? Why not just include all that "optional" code in the pages generated by the Android Studio Wizard (by using that wizard to ask "Do you want your app to do this, this and this?") in the first place? It sounds like Android Studio and Firebase are ultimately both by Google anyway, so why not do that, and also, why not just package Firebase itself into Android Studio and just have "testing" and "publish" options available from within Android Studio, thus making it all developer-side coding rather than server-side coding? Honestly? Why does this have to be so hard and complicated? I'd love to just be able to import my databases (of all formats), have them converted over to .json (like the free CSV to JSON app from Windows 10's store does), and have FireBase's database tool also integrated into Android Studio (along with all the other FireBase tools) in the first place, and save everyone all these complicated headaches.

    Maybe you think this isn't complicated because your coddled coding butt has been pampered by sitting on daddy's or uncle's or male-coding-teacher's knee since you were a toddler, but that's just not the luxury that a lot of us, especially those of us who are now middle-aged-women (who were told we should play with Barbies instead and not given those same opportunities that you'll never truly appreciate the way you should), were ever given. Many of us having been fighting a battle you'll never grasp, primarily because you're white, you're male, and you're far too young to have even been there… Opportunities were directly deleted from our grasp by your dad's and grand-dad's generation. I can tell that you've been coddled since early childhood this way: buddy, you go way too fast for the kind of information you're dealing with here. The least you could have done was include the code snippets in the summary below the video… (Your web page link up there is hardly obvious as to what it is or why anyone should click on it – you need to fix that, but really, it's better to include the text in the summary under the video, for those who miss the link.)

    Bottom line is, yes, in this case, this all is way too complicated, and the glorious horror about this is that it doesn't have to be*. You all need to get together with the creators of Android Studio and whoever made that CSV to JSON Windows 10 app, and redesign this entire system so it's actually easy and not *this stupifyingly complex (again, when it *deosn't have to be*).

    Rule #1: If you're having to make a video to tell the world, "Add this code to the pre-generated files from this application in order to make your program do anything worth doing at all," then chances are, you need to just integrate that code into the pre-generated files from that application in the first place. This entire video shouldn't have been necessary, and I'm guessing that most of the other related videos really aren't necessary either. Developers shouldn't be having to make up for the fact that all these different coding application and web based components haven't been integrated properly with each other. That's your problem to deal with – it shouldn't be ours.

  5. Follwed this guide
    And getting -> Execution failed for task ':app:processDebugGoogleServices'.
    > No matching client found for package name

  6. Isn't Firebase Crash reporting deprecated now in favour of Crashlytics? Might be worth mentioning or removing this video.

  7. What is the use Firebase crash reporting ,Does it provide more than that is recorded in developer console? I can see the crashes and log reports even in google developer console.

Leave a Reply

Your email address will not be published. Required fields are marked *