chore(android): clear the Gradle 10 deprecations, verified against the artifacts

[doublegate]

Four call sites the Android build was warning about, each checked against the
actual artifact rather than against the warning text.

What the build was saying

• AndroidSourceDirectorySet.srcDir(Any) — "Use directories mutable set
  instead" (two sites).
• Two Kotlin DSL delegated properties (by tasks.registering(Exec::class)),
  three warnings apiece, pointing at the Gradle 9.6 upgrading guide.
• currentWindowAdaptiveInfo() — "Please use V2 version of this function to
  support L and XL width size classes."
• And the summary: "Deprecated Gradle features were used in this build, making
  it incompatible with Gradle 10."

Verified, not inferred

The version I read first was the wrong one. AndroidSourceDirectorySet came
out of the AGP jar the local Gradle cache happened to hold — 9.2.1 — while
the build pins 9.3.2, and the warning came from 9.3.2. Re-read from the
pinned artifact, downloaded for the purpose. The interface is identical, so the
fix stands — but it stood on the wrong evidence until it was checked.

What the interface actually says: getDirectories() returns Set<String>, so
the replacement takes paths and the call sites pass .path, not the File.
That is not deducible from "use directories mutable set instead".

currentWindowAdaptiveInfoV2 was confirmed present in material3.adaptive
1.3.0 by extracting the AAR — and confirmed absent in 1.2.0, which is what
made this change depend on #469 rather than being independent of it. It is
sequenced after that merge for exactly that reason.

Gradle's upgrade guide is explicit on the delegates: registering, creating,
existing and getting are all deprecated and scheduled for removal in
Gradle 10, replaced by register, create, named and getByName.

Behaviour

Unchanged. Both breakpoints tested against the adaptive info are "at least", so
a window that now reports the new L or XL width class still satisfies EXPANDED —
V2 reports more classes, it does not reclassify the ones already handled.

The warning that names nothing

The build now runs with --warning-mode all. Gradle's summary line says the
build is incompatible with Gradle 10 and identifies not one cause; Gradle itself
says the flag is how you find out. A warning that cannot be attributed is a
warning nobody acts on, and this one has a deadline attached.

Verification

android.yml runs on this PR. Its Gradle bundle job is continue-on-error, so
its conclusion is not evidence — the step results and the build log will be
read before this is called green.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9213cf6e-6a7b-4f6e-ae03-7b8b4443f81b

Warning

Your free Security trial is over. An organization admin can activate billing to continue.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[github-actions]

Antigravity review (Gemini via Ultra)

This PR clears Gradle 10 deprecations by updating Kotlin DSL task registrations, using AGP's updated source directory properties, migrating to the V2 adaptive window info API, and surfacing detailed warning logs in CI.

Blocking issues

• Build Crash / Correctness: In android/app/build.gradle.kts, calling .add() on the .directories collection is highly likely to throw an UnsupportedOperationException during configuration. Java interfaces mapping to Kotlin MutableSet do not guarantee runtime mutability, and AGP/Gradle getters notoriously return unmodifiable view collections. Because the commit states this was verified against the interface rather than by executing the build, you must run-test this to guarantee it does not panic.

Suggestions

• android/app/build.gradle.kts (lines 200-203), MainActivity.kt (lines 1017-1022), and .github/workflows/android.yml (lines 147-154): Remove the conversational PR descriptions. The style guide strictly mandates: "Do not add user-facing comments or descriptions of your changes." Code comments must explain the why of the current system, not serve as a ledger of why deprecations were cleared.
  • For android.yml, condense the block to something like: # Enable --warning-mode all to surface actionable deprecation traces instead of a generic summary.

Nitpicks

• CHANGELOG.md: The added entry reads like an internal PR review justification. Condense it to state the actual change without the paragraphs of technical defense.

_{Automated first-pass review by agy on a self-hosted runner -- not a human review.}

[doublegate]

Replying to the Antigravity review

Blocking issue — .directories.add() may throw UnsupportedOperationException: declined, refuted by execution.

The finding is a good one and its criticism of my evidence was fair: the commit said "verified against the interface", and an interface returning Set<String> does not promise a mutable set. Gradle and AGP getters do often hand back unmodifiable views.

But the run-test you asked for had already run, on this PR. The Gradle bundle foss+play release job's Bundle release AABs (foss + play, unsigned) step executed the changed configuration and reports:

BUILD SUCCESSFUL in 18m 23s

Eighteen minutes, both flavours, Compose compilation and R8 included. Configuration is the first thing Gradle does — an UnsupportedOperationException there aborts before a single task runs, so this outcome is not compatible with the collection being unmodifiable.

Worth flagging one thing about that job for future reviews, because it cuts the other way and is easy to be misled by: it is continue-on-error: true, so its conclusion is not evidence of anything. Only the step results and the log are. That is why the log line is quoted here rather than the green tick.

Suggestion — remove the "conversational" comments: declined.

This is a genuine style disagreement rather than an oversight. AGENTS.md asks for comments that "explain the why alongside the architectural detail", and this repository's convention deliberately records what was measured — including what an earlier version got wrong and what caught it. The srcDir comment exists because the replacement's element type (Set<String>, so .path and not the File) is not deducible from the deprecation message; the V2 comment exists because the behavioural equivalence ("both breakpoints are at least") is the non-obvious part.

I take the point that a comment should not read as a changelog entry, and if any of these drift that way they are worth trimming. But the measurements themselves are the content, not decoration around it.