chore: upgrade to Gradle 9.7.1 and AGP 9.4.0

[bobbyg603]

Why

The build machine runs JDK 26.0.1, which Gradle 8.13 and AGP 8.6.1 cannot parse. The build dies during startup with the version string as its entire error message:

* What went wrong:
26.0.1

Pinning that machine to an older JDK would work, but the toolchain is a year behind and the next release has to come off that machine.

Gradle 8.13 → 9.7.1, AGP 8.6.1 → 9.4.0, com.vanniktech.maven.publish 0.30.0 → 0.37.0 (older versions do not support AGP 9).

AGP 9 breaking changes handled here

android.libraryVariants was removed. The AAR rename that produces bugsplat-android-release.aar now runs from androidComponents.onVariants. It matches the bundle task by name rather than calling tasks.named(...), because AGP 9 does not create bundleDebugAar — naming it directly throws UnknownTaskException.

Library variants are no longer publishable implicitly. Unable to find variant to publish named release until the plugin is told which variant to publish. Note the call is delegate.configure(...): a bare configure(...) inside the mavenPublishing block resolves to Project.configure in a Groovy build script and silently does nothing. Declaring publishing { singleVariant('release') } in the android block instead fails with Using singleVariant publishing DSL multiple times, since the plugin already declares it.

publishToMavenCentral no longer takes a SonatypeHost. The Central Portal is the only host it publishes to now, so the argument was removed — leaving it produces Could not get unknown property 'com'.

Verification

Check	Result
:app:assembleRelease	pass
:app:testDebugUnitTest	pass
:example:compileDebugJavaWithJavac	pass
bugsplat-android-release.aar rename	still produced
libbugsplat_handler.so packaged	present for arm64-v8a, armeabi-v7a, x86_64

That last row matters: the handler wrapper from #26 is new native output, and the AAR rename and CMake packaging are exactly what the AGP upgrade touches.

Not verified: publishing. publishToMavenLocal fails here with No configured signatory — no PGP key on this machine. The publish configuration is only proven as far as configuration time; whoever holds the key should run ./gradlew publishToMavenLocal on this branch before it merges, since the publish DSL changed.

Not included

• Kotlin stays at 1.9.0. The plugin is declared in the version catalog but applied nowhere, and the only .kt files are unused template tests. Bumping or removing it is a separate cleanup.
• gradlew/gradlew.bat/gradle-wrapper.jar are regenerated by ./gradlew wrapper, so the diff includes them.
• Gradle reports the build still uses features "incompatible with Gradle 10" — not investigated here.

[Copilot]

🟡 Changes recommended

The updated gradlew.bat does not reliably terminate on “no Java / invalid JAVA_HOME” error paths, so it can continue executing after printing an error.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Upgrades the project’s build tooling (Gradle wrapper + Android Gradle Plugin + Vanniktech publish plugin) to support running on JDK 26.0.1, and updates the AAR renaming/publishing wiring for AGP 9 breaking changes.

Changes:

• Bump Gradle wrapper to 9.7.1 and update generated gradlew / gradlew.bat scripts.
• Bump AGP to 9.4.0 and com.vanniktech.maven.publish to 0.37.0 via the version catalog.
• Update app/build.gradle to use androidComponents.onVariants for AAR renaming and adjust the publish configuration for AGP 9.

File summaries

File	Description
gradlew.bat	Updated Windows wrapper script for Gradle 9.7.1 (found an early-exit bug).
gradlew	Updated POSIX wrapper script for Gradle 9.7.1.
gradle/wrapper/gradle-wrapper.properties	Points wrapper to Gradle 9.7.1 and adds wrapper network settings.
gradle/libs.versions.toml	Updates AGP and maven publish plugin versions.
app/build.gradle	Updates publishing config and switches AAR renaming to androidComponents.onVariants for AGP 9.

Review details

Suppressed comments (1)

gradlew.bat:68

• Same issue here: "%COMSPEC%" /c exit 1 does not terminate the current gradlew.bat process, so the script can continue on to :execute with an invalid JAVA_HOME and fail later with a less clear error.

echo. 1>&2
echo ERROR: JAVA_HOME is set to an invalid directory: %JAVA_HOME% 1>&2
echo. 1>&2
echo Please set the JAVA_HOME variable in your environment to match the 1>&2
echo location of your Java installation. 1>&2

"%COMSPEC%" /c exit 1

• Files reviewed: 5/6 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[bobbyg603]

Declined — gradlew.bat is generated, not hand-written.

The claim about batch semantics is correct: "%COMSPEC%" /c exit 1 sets ERRORLEVEL in a child cmd and execution continues, so with no JAVA_HOME and no java on PATH the script prints the first error, falls into :findJavaFromJavaHome, prints the second, then reaches :execute. The process still terminates non-zero via "%COMSPEC%" /c exit %ERRORLEVEL% on line 82, so the failure is reported — the cost is a confusing second error message, not a false success.

But this file is produced verbatim by Gradle 9.7.1's wrapper task. Re-running ./gradlew wrapper --gradle-version 9.7.1 on this branch reproduces the committed file byte-for-byte, so any hand-edit here would be silently reverted the next time anyone regenerates the wrapper, and would leave the repo diverged from the script Gradle ships and verifies.

It shows up in this diff only because the wrapper moved from 8.13 to 9.7.1 — origin/main's gradlew.bat contains no COMSPEC lines at all. If the fall-through is worth fixing it belongs upstream in gradle/gradle, not in this PR.