chore(deps): update gradle to v9.7.0

[renovate]

This PR contains the following updates:

Package	Update	Change
gradle (source)	minor	9.6.1 → 9.7.0

---

Release Notes

gradle/gradle (gradle)

v9.7.0

Compare Source

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[claude]

Claude finished @renovate[bot]'s task in 1m 28s —— View job

---

Review: Gradle wrapper 9.6.1 → 9.7.0

• Gather PR context and diff
• Verify distribution SHA-256 against upstream
• Verify wrapper jar integrity against upstream
• Check toolchain / AGP compatibility
• Check for stale version references elsewhere in the repo
• Post review

Verdict: Looks good — safe to merge once CI is green. No blocking issues, no suggested changes.

---

Supply-chain verification (the part that actually matters here)

This PR swaps a binary (gradle-wrapper.jar) that executes on every developer machine and CI run, so I verified both artifacts against the official Gradle release checksums rather than trusting the diff:

Artifact	Value in PR	Official 9.7.0	Match
distributionSha256Sum (gradle-wrapper.properties:3)	84fbba45…d873ae	84fbba45c7f4c64abc77460e1c00f541e9f960e3c7ed2538f1ede19eacd873ae	✅
gradle-wrapper.jar (computed locally, sha256sum)	7a9ce74c…62c5d	7a9ce74cff467ca1bf60a4fcd9f05185acceda4d0f382434d393e17864262c5d	✅

Both are exact matches. The jar is the genuine upstream 9.7.0 wrapper, and the pinned distribution hash is the genuine 9.7.0 -bin zip — so the wrapper will hard-fail rather than silently proceed if the downloaded distribution is ever tampered with.

Also confirmed still intact in gradle/wrapper/gradle-wrapper.properties:

• validateDistributionUrl=true — kept, so the distribution URL is checked before download.
• distributionUrl points at services.gradle.org over HTTPS, not a mirror.

Compatibility

• JDK: CI runs Temurin 21 (.github/workflows/android-ci.yml:26, .github/workflows/release.yml:54). Gradle 9.7 runs on 21 — fine.
• AGP: agp = "9.3.1" and Kotlin 2.2.21 (gradle/libs.versions.toml). AGP 9.x targets the Gradle 9.x line, so a 9.6.1 → 9.7.0 minor bump stays inside the supported range.
• Stale references: grepped the workflows, docs, and build scripts — no Gradle version is pinned anywhere else. The only other mention is a historical CHANGELOG.md:95 entry ("Upgrade to AGP 9.0.1 and Gradle 9.2.1"), which is a past release note and correctly left untouched.

Code quality / bugs / performance

Nothing to flag. The change is two lines plus a vendored binary, contains no project code, and touches no logic — so the usual review dimensions (bugs, readability, performance) don't apply beyond the integrity checks above.

One non-blocking observation, not a defect: Renovate updates gradle-wrapper.jar and .properties but leaves the gradlew / gradlew.bat launcher scripts alone. Those scripts are stable across Gradle releases and are not version-pinned, so this is expected and harmless. If you ever want them regenerated in lockstep, ./gradlew wrapper --gradle-version 9.7.0 does it — but there's no reason to do so for this PR.

Validation

I verified the checksums and configuration statically but could not run a build locally — ./gradlew --version and the distribution download are blocked by the sandbox in this environment, so I have no local build result to report. The real signal is CI, which was still in progress when I checked (Android CI and Qodana both pending). Please confirm Android CI passes before merging; that run is what actually exercises the new distribution end to end.

Follow-ups

None required.

--- · Branch renovate/gradle-9.x

[github-actions]

Qodana for JVM

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked
☁️ View the detailed Qodana report

Contact Qodana team

Contact us at qodana-support@jetbrains.com

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions