feat(cli): warn when Java is too new for the bundled Gradle

[tenderdeve]

Closes #15385

Installing a very recent JDK (Java 25/26) while Tauri ships Gradle 8.14 makes Android builds fail with a cryptic Failed to assemble APK with Io... error that gives no hint about the real cause.

This adds an upfront check to the Android env setup (runs for android init/dev/build): detect the active Java feature version via java -version (preferring JAVA_HOME) and log::warn! when it's newer than the bundled Gradle can run on, pointing at the Gradle/Java compatibility matrix and suggesting a supported JDK.

The ceiling is a MAX_SUPPORTED_JAVA constant next to the existing NDK_VERSION/SDK_VERSION constants, to be bumped alongside the template's Gradle version. It's a warning only — nothing is blocked.

Added a unit test for the version parser covering the modern (21.0.1), single-number (26) and legacy (1.8.0_292) schemes.

[github-actions]

Package Changes Through 310ed2b

There are 14 changes which include tauri with minor, tauri-cli with minor, @tauri-apps/cli with minor, tauri-runtime with minor, tauri-runtime-wry with minor, tauri-utils with minor, tauri-bundler with minor, tauri-build with minor, tauri-macos-sign with minor, tauri-codegen with minor, tauri-macros with minor, tauri-plugin with minor, tauri-driver with minor, @tauri-apps/api with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
@tauri-apps/api	2.11.1	2.12.0
tauri-utils	2.9.3	2.10.0
tauri-macos-sign	2.3.4	2.4.0
tauri-bundler	2.9.4	2.10.0
tauri-runtime	2.11.3	2.12.0
tauri-runtime-wry	2.11.4	2.12.0
tauri-codegen	2.6.3	2.7.0
tauri-macros	2.6.3	2.7.0
tauri-plugin	2.6.3	2.7.0
tauri-build	2.6.3	2.7.0
tauri	2.11.5	2.12.0
@tauri-apps/cli	2.11.4	2.12.0
tauri-cli	2.11.4	2.12.0
tauri-driver	2.0.6	2.1.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[tenderdeve]

@Legend-Master good point on the build overhead — I dropped the java -version subprocess in 91eb1e4. It now reads the major version straight from the JDK's release file (the JAVA_VERSION= line), preferring JAVA_HOME and falling back to the java on PATH. No process spawn on init/dev/build, and if the file isn't there or doesn't parse it just skips the warning rather than doing anything expensive.

[tenderdeve]

@Legend-Master good point — you're right that pinning to the template's Gradle version is wrong once the user upgrades their wrapper. Reworked in 7a95ab775: instead of a hardcoded constant, it now reads the Gradle version straight from the project's gradle/wrapper/gradle-wrapper.properties (distributionUrl) and only warns when the detected Java is too new for that Gradle. If the project isn't generated yet, the file can't be parsed, or it's Gradle 9+ (which tracks new Java quickly), it stays silent — so no false warnings. Still no subprocess spawn.

[Legend-Master]

Could you give this a spin see how long the whole process takes? Also let's move those checks to a dedicated file.

[tenderdeve]

@Legend-Master pushed ec4f795:

• Dedicated file — moved ensure_java and the Java/Gradle helpers into crates/tauri-cli/src/mobile/android/java.rs; mod.rs just calls java::ensure_java() now. Tests moved with it, plus one for the Gradle→Java mapping.
• Exact recommendation — dropped the vague "LTS such as Java 17 or 21" line; the warning now points at the concrete ceiling for the project's Gradle (Install a JDK that Gradle {gradle_version} supports (Java {max_java} or older)).
• Build overhead — the earlier version's cost was the java -version subprocess, which is already gone: detection now reads the JAVA_VERSION= line from the JDK's release file and the Gradle version from gradle-wrapper.properties, so it's two small file reads (sub-millisecond), no process spawn. I don't have a full Android toolchain on this machine to give you an end-to-end build timing — happy to if you have a quick way to get numbers on CI, but the added work here is negligible either way.