[firebase_crashlytics] Migrate to new Crashlytics SDK

[axel-op]

Description

This PR updates the Crashlytics implementation to use the new SDK, which doesn't use the Fabric SDK anymore: https://firebase.google.com/docs/crashlytics/get-started-new-sdk.

Related Issues

• Fixes [firebase_crashlytics] Migrate away from Fabric #2038
• Fixes [firebase_crashlytics] <README not updated> #2379
• Fixes [firebase_crashlytics] Add [FIRApp configure] (FirebaseApp.configure() in Swift) to your application initialization #1411
• Fixes [firebase_crashlytics] incomplete documentation #1153
• Fixes [firebase_crashlytics] runZoned with onError is deprecated in version v1.17.0 #2361

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• If the pull request affects only one plugin, the PR title starts with the name of the plugin in brackets (e.g. [cloud_firestore])
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[MaikuB]

@axel-op I believe the title of the PR needs amending to start with [firebase_crashlytics] instead of [crashlytics] as it's the name of the plugin that should be used

[axel-op]

@MaikuB Thanks, it's done. What do you think of the PR?

[MaikuB]

@axel-op I'm not familiar with the APIs to comment. Came across your PR as another member in the community mentioned it :)

[axel-op]

I'll definitely need help for the iOs part.

[workerbee22]

What do we need to do to get this moving ... it's already very urgent.

[axel-op]

I have to update the README file

[workerbee22]

Wow ... @axel-op great progress 🎉🎉🎉

[workerbee22]

Looking good, just some beta version updates.

[axel-op]

Looks like they have moved to beta4 as per the official doco here

Thanks @workerbee22 for pointing that out :)

[axel-op]

@workerbee22 and @creativecreatorormaybenot is everything OK for you?

[creativecreatorormaybenot]

It seems as though my feedback has been addressed 👍🏼
Need some testing now to confirm that everything works as expected and a maintainer to take a look at this.

[axel-op]

Well, I was just asking for your opinion, since I knew you would answer much faster ;)

[workerbee22]

LGTM

[axel-op]

@axel-op I'm skeptical about that as all that should already be handled and a lot of plugins that wrap around native SDKs work in a similar way without issues. I would think there's something else going on there that I wouldn't read too much into it unless a complete sample app can be provided to demonstrate it's needed. For what it's worth I work on an app that hasn't needed those steps and would expect it to be a more widespread issue if it was needed

Noted 👍

[MaikuB]

@MaikuB Also while testing I had to update my AppDelegate file like so. But I'm really not an expert in iOS development, so I'd really like to have a confirmation from an iOS developer.

If that's the case then it worth debugging the plugin further as it could mean that this isn't being called.

One alternative is to have the plugin register to receive AppDelegate calls and call configure like you currently do in the example app's AppDelegate.swift file. This would (1) remove the need to have developers do it themselves and (2) more closely mirror the setup required by a native iOS app. An example of how to have the plugin register to receive these calls can be found here. Not sure if there was a reason why it wasn't originally done this way though

[axel-op]

@MaikuB Thanks! I'm not sure I should make these changes right now, as I believe the current rework by the people from Invertase will probably bring some important changes to the native part of all Firebase plugins, as this comment suggests.

[Ehesp]

With the upcoming changes, firebase_core will be required for other plugins to work. Part of the setup steps will be to ensure that the user adds these lines into your AppDelegate file.

We should have a PR up soon which overhauls Core, along with other changes (CI, tests etc) so it'd make more sense to sync this work up with that.

[MaikuB]

@Ehesp has the team looked at minimising the amount of code users need to put into their AppDelegate file as well? Flutter already provides mechanisms for plugins to receive AppDelegate calls. It looks like there's potential opportunity to do that in this PR as well

[Ehesp]

Yep that was a terrible example, we're doing that already - will link to the PR when it's up.

[thomas-stockx]

This is slowly getting urgent as the Firebase team is sending out automated emails in regards to the Fabric Crashlytics SDK now being officially deprecated and will stop working on November 15, 2020.

[jpelgrim]

This dependency is already in the firebase_crashlytics package ./android/build.gradle file, right? We don't need to add it to our Flutter app build.gradle file IMO.

Update: Works fine without it in my case. I don't think the whole fourth step is needed. It's even a bit confusing and misleading to add the firebase-analytics dependency too here since it's not necessary for Firebase Crashlytics to work.

[MaikuB]

Yeah if it's already a dependency used by the plugin then developers shouldn't need to add it to their app's build.gradle file

cc @axel-op

[workerbee22]

Ditto for the firebase_analytics ! I don't like the way the official documentation like this: https://firebase.google.com/docs/flutter/setup?platform=ios

Encourages other packages. It just leads to possible reader confusion.

[axel-op]

This will be updated when the package will depend on the new versions of firebase_core.

[gaetschwartz]

Do we have any updates on the status of this PR @axel-op ? I can help if needed but I'm pretty sure this PR is becoming quite urgent and it would be great to be able to push it asap ;)

[tillchen]

Any updates? The discrepancy of documentations is very confusing now.

[axel-op]

Do we have any updates on the status of this PR @axel-op ? I can help if needed but I'm pretty sure this PR is becoming quite urgent and it would be great to be able to push it asap ;)

I'm gonna work on it this weekend.

[axel-op]

I think that we should now wait for the new releases of firebase_core that should be published next week.

[ened]

@axel-op @Ehesp What is a good way to support NDK crash reports using the new SDK? See this page for a example on the native integration: https://firebase.google.com/docs/crashlytics/ndk-reports

It seems that integration of NDK crash reports requires a dependency change and some additional gradle configuration. Perhaps it is enough to mention it in the README?

[donguseo]

I think that we should now wait for the new releases of firebase_core that should be published next week.

firebase_core-v0.5.0-dev.1 is released! When will this pr be merged?

[Salakar]

Hey everyone, good news; Crashlytics has been bumped to the top of the priority list on the roadmap #2582 - so we'll be looking at this next.

What would be helpful is if anyone that has been using this PR in production could respond here if there's still any outstanding issues they've discovered while using the code in this PR, thanks!

---

@axel-op if you're willing, do you have any form of messaging so we can chat quicker and help get this PR merged quicker? I'm Salakar#1337 on Discord, or @mikediarmid on Twitter if any of these work for you.

[Ehesp]

Hey all 👋 I've started the process of breaking out the work done by @axel-op into a federated plugin setup, along with some QOL updates to get it ready for review and release.

The PR is in-progress here https://github.com/invertase/flutterfire/pull/41

Thanks again for this contribution @axel-op 🥳

[axel-op]

@Ehesp Thanks ☺️

[gaetschwartz]

Any updates on this PR ? ☺

[Ehesp]

Nope, currently going through updates and review still.

[gaetschwartz]

Is there progress on this PR ? And is there any way for me to help ? Would gladly help is you need some ;)

[yringler]

@blaxou , the PR is under active development, but at a new location https://github.com/invertase/flutterfire/pull/41. Latest activity was 4 days ago.

[Salakar]

Closing in favour of #3420