`injectCrashlyticsMappingFileIdRelease` causes every release build to be invalidated

[brettwillis]

The injectCrashlyticsMappingFileIdRelease task from the Crashlytics plugin is always invalidated on release builds, and generates a new unique ID into the app's resources, which causes the entire build and bundling to be invalidated even when nothing has changed.

I see from https://github.com/firebase/firebase-android-sdk/issues/5925#issuecomment-2092837896 that this behaviour is intentional only due to other limitations, although known to be less than ideal.

So I'm opening this issue as my vote for it to receive some attention until this less-than-ideal behaviour is resolved.

Some thoughts off the top of my head:

• Do app resources affect the mappings/stack traces? I'd think it would just be source code? If not, then the task need not have a dependency on resources files (doesn't care when resources have changed). Then that circular dependency mentioned in the referenced issue might be resolved.
• Is there another way to identify the stack trace mapping file in the Crashlytics backend without needing to inject a unique ID at all? E.g. Crashlytics on iOS does not do this because I think dSYMs there have unique GUIDs anyway?

---

• Android Studio version: n/a
• Firebase Component: Crashlytics
• Component version: com.google.firebase:firebase-crashlytics-gradle:3.0.3

[lehcar09]

Hi @brettwillis, thank you for raising the issue and sharing your thoughts. From what I gather, app resources does not affect mapping, only source code. As for the second question, let me consult this with our engineer and get back to you. Thanks!

[lehcar09]

Hey @brettwillis, according to our Engineer,

This has been considered before, but the problem is that mapping files have no unique id like symbol files do. So we generate a random id in Crashlytics and associate it with the mapping file and with the crash. But that random id is generated every build.

We are still exploring potential solutions. However, we are unable to promise any timeline for this. With that, I'll go ahead and mark this as a feature request.

P.S. For folks who find this useful, adding an emoji thumbs up on the original post can help us prioritize adding this to the roadmap.

[brettwillis]

Hi @lehcar09 thanks for your effort investigating this!

Given your indication that app resources do not affect the source mapping, perhaps that may hold the solution. Currently there's a circular invalidation loop: generation of random ID injects into app the resources, which invalidates the resources, which causes a new ID to be generated on the next build (because the injectCrashlyticsMappingFileIdRelease task depends on the app resources), so every build is invalidated. If indeed the app resources do not affect the mapping file, then then injectCrashlyticsMappingFileIdRelease may not depend on app resources (it's own output), and only re-run when the sources are changed, thus not invalidating every build.

Either way thanks for noting the feature request. It will sure be great once we can properly utilise our build cache.

[dugsmith]

I wrote the duplicate #7185 before I knew about this one. Thank you for looking into this!