This article was also published on ProAndroidDev: See Here
Last week I setup a project to use Crashlytics for Android as our crash reporting tool.
Use Crashlytics (NEW) and Perf Monitoring to increase app retention and keep users happy! #FirebaseSummit live → https://t.co/eSmn1vZtaf
This week, at the Firebase Dev Summit, support was announced for Crashlytics issue reporting from within your existing Firebase console.
Since I prefer to use as few different service consoles as possible, I wanted to migrate over to the new Firebase Crashlytics reporting. It was a pretty straightforward process with a couple small gotchas, so I thought I would share what I found.
A while back, I wrote about simplifying our app distribution process using Beta by Crashlytics.
Simplifying App Distribution with Beta by Crashlytics
Since that time, I had been thinking (and receiving questions) about how to handle multiple buildTypes and productFlavors more gracefully. When I originally described our approach we only needed to worry about a single build target. After a while, we added a second productFlavor and the fastest solution was to simply copy our custom gradle tasks and make new versions for the new build target.
That solution got us up and running quickly, but it always bothered me that we now had a sizable chunk of duplicate code in our gradle file. When it came time to add yet another product flavor, the time had come to think about a better solution
Thankfully, it was pretty easy to leverage the power of gradle to create custom distribution tasks for each buildType/productFlavor combination without having to manually duplicate any code.