[Crashlytics] Fix release build cache invalidation

[jrodiz]

Crashlytics: content-driven mapping file id for release builds

Fixes #6770

injectCrashlyticsMappingFileIdRelease minted a new UUID on every release build, cascading through mergeResources → processResources → R8 → packaging and breaking the build cache for every minified release.

This PR makes the task content-driven: Gradle's input snapshotting decides when to re-execute. While the variant's user sources are unchanged, the task stays UP-TO-DATE and the entire downstream cascade stays cached. When sources change — which is when R8 would produce a different mapping.txt — the task re-runs and a fresh id is minted.

How

• useBlankMappingFileId promoted from @Internal to @Input (mode flip natively invalidates).
• New @InputFiles obfuscatableSources populated from project.fileTree("src") with java/** + kotlin/** patterns (tests excluded). Path-based, no task deps — sidesteps the cycle that variant.sources.*.all would close through AGP's resource graph.
• Custom upToDateWhen and on-disk reuse path removed.

Verification

• :spotlessApply, :validatePlugins, :test, :functionalTest — green (19/19).
• End-to-end manual repro: github.com/jrodiz/repro6770 (AGP 9.1.0-alpha05, Gradle 9.2.1, compileSdk 36, real Firebase project). Pre-fix plugin 3.0.3 flips mappingFileId.txt every rebuild and re-runs the full cascade. With this branch (mavenLocal()), the id stays byte-identical across rebuilds, every downstream task is UP-TO-DATE, second assembleRelease finishes in ~1s. Editing a Kotlin source mints a new id; clean and mappingFileUploadEnabled toggle behave as expected.

Verification from manual test plan above

• End-to-end manual verification in a real Android app: github.com/jrodiz/repro6770 (AGP 9.1.0-alpha05, Gradle 9.2.1, compileSdk 36, isMinifyEnabled = true, real Firebase project).
  • Reproduced the bug against the published pre-fix plugin com.google.firebase.crashlytics:3.0.3 — mappingFileId.txt flipped every rebuild (f5f0310… → 6514b43…), and :app:processReleaseResources, :app:uploadCrashlyticsMappingFileRelease, :app:packageRelease, :app:assembleRelease all re-executed with no source changes.
  • Verified the fix by publishing this branch to mavenLocal() as 3.0.7 and bumping the app's plugin version — mappingFileId.txt stays byte-identical across rebuilds, :app:injectCrashlyticsMappingFileIdRelease reports UP-TO-DATE, and the full downstream cascade (:mergeReleaseResources, :processReleaseResources, :minifyReleaseWithR8, :packageRelease, :assembleRelease) is UP-TO-DATE. Second assembleRelease finishes in ~1s.
  • Verified clean still mints a fresh id, and toggling mappingFileUploadEnabled = false re-runs the task and writes the blank id 0…0.
  • Full transcript with task outcomes and id values in TEST_RESULTS_ISSUE_6770.md.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

[jrodiz]

@OOS93 Applied your suggestion

[mrober]

We tried something like this before, it looked more like this.sourceFiles.from(variant.sources.java?.all, variant.sources.kotlin?.all)

But this created circular dependencies when apps used things like compose. If source depends on resources, and resources depend on sources, we have a circular dependency. Can you confirm if this has the same problem?

[jrodiz]

Ran both implementations against the real repro6770 app

App configuration	variant.sources.java?.all + kotlin?.all	Current fileTree("src")
Compose only	builds, no cycle	builds, no cycle
Compose + viewBinding	Circular dependency — BUILD FAILED	builds; inject SUCCESS → UP-TO-DATE; id stable

Compose alone is not a trigger, the trigger is view/data binding. So the circular dependency will only be present if I use variant.sources.java?.all + kotlin?.all + view/data binding.

The project.fileTree("src") form builds cleanly on the same app (task UP-TO-DATE on rebuild, stable id) because it's a plain FileTree: no builtBy/task-dependency edges for Gradle to order against, and it only scans src/**. Never build/generated/** where the binding-generated sources live.