Matthew Robertson

Crashlytics relies on these disk reads because of the way it ensures all information captured during the last crash is processed and uploaded properly. These disk reads don't happen on...

Hi @mposch-Z, we looked into this and think we found the source of the problem is that the google services plugin isn't reprocessing the google-services.json file after it's been updated....

We are aware of this inconsistency between iOS and Android. We're considering making the two platforms consistent, but it's not a priority right now. We're hesitant because it would change...

Thanks for the suggestions. We will keep the user info as a feature request. We discussed switching custom keys to retain the most recently set keys, but decided not to...

The file operation is part of a check that Crashlytics does to ensure the app has launched successfully. This increases reliability of crash reporting for apps that crash on launch....

I took a look at this, and here is what's going on. The google-services plugin isn't generating a task for the dynamic module, and the Crashlytics plugin depends on that....

Closing since this is the same issue.

This is because the `injectCrashlyticsMappingFileId` task generates a random mapping file id as an Android resource. But we didn't want it to make new random id on every build if...

Thanks for the details everybody! I have implemented a fix for this and verified it with viewBinder. I also added new functional tests that validate use cases with code generation....

@Tolriq the `googleServicesResourceRoot` was an implementation detail. Our instructions don't tell you to use it anymore. It was a deliberate decision to remove that, since now the Firebase Google-Services plugin...