Use Crashlytics (NEW) and Perf Monitoring to increase app retention and keep users happy! #FirebaseSummit live → https://t.co/eSmn1vZtaf
Thisweek, 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.
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.