Build1 publisher2 min readPublished
A Java 25 upgrade stops Flutter Android builds still pinned to Gradle 8.14
Flutter's deprecation notice and its Java 25 incompatibility error both put the floor at Gradle 9.1.0, so a developer whose machine tools moved forward lost an Android build while the project stayed exactly as it was.
The Engineer · Build desk
What happened
- A dev.to author's Flutter app stopped building after a machine tool upgrade, with the error reporting that the Java version used for the build, 25.0.3, is incompatible with Gradle 8.14.
- Flutter's error also offered a route that leaves the build files untouched: point the tool at another Java version by running flutter config --jdk-dir with a path.
- The author found his Android Studio was still the older Panda 4 release and downloaded the Quail 4 tarball, then updated SDK platforms and tools through the SDK Manager.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A team on Gradle 8.14 now picks between a Gradle 9 wrapper migration and a per-machine JDK override through flutter config, and the override has to be set on every workstation and build agent that gets a new Java.
- exposure Any developer whose version manager tracks latest can reach the failing pair without a commit, so the break arrives one machine at a time and looks like a local problem.
- cost Regenerating the android directory is close to free on a scaffolded app, and it becomes a merge job for anyone carrying signing config, manifest edits or custom Gradle plugins in there.
- constraint With Java 25 on the machine, the Gradle 9 wrapper bump is a precondition for compiling at all.
The two version numbers in that failure come from different places. Gradle's version is committed to the repository, in gradle-wrapper.properties, which is where Flutter's error tells you to raise it [4]. The JDK is whatever the machine hands the build, and here it was 25.0.3 [3]. The author writes that he had upgraded a few tools on the machine and that the application had run without problem the last time [8]. The post does not say which of those tools installed Java 25 [20].
The run died fast. Gradle reported BUILD FAILED in 1s, and Flutter's own timer put the assembleDebug task at 1,270ms [7]. About 1.3 seconds is the version check firing, before the app is compiled [17].
Two gates fired in the same run. Flutter printed a warning that support for Gradle 8.14.0 "will soon be dropped" and asked for at least 9.1.0 [1], and offered `--android-skip-build-dependency-validation` to bypass that check [2]. The fatal error came separately, with its own remedies: raise the wrapper into the compatible range, or set a different JDK for Flutter [4][5]. The skip flag answers the validation warning, so suppressing the warning does not make Java 25 work with Gradle 8.14 [19].
Both messages land on the same number. The deprecation notice wants 9.1.0 or newer [1], and the compatible range for Java 25.0.3 starts at 9.1.0 [4], so the wrapper bump that unblocks the JDK is the bump the deprecation was going to force anyway [16].
The task that failed was `:app:compileFlutterBuildDebug`, and Gradle's complaint was that it could not start the flutter binary under `~/.local/share/mise/http-tarballs/` [6]. That path segment is a 64-character hex digest [18]. The project's `.tool-versions` asks for whatever is current: it reads `flutter latest` and `dart latest`, and `mise upgrade` is what moved them [9].
The machine side got the same sweep. Android Studio went from Panda 4 to Quail 4 [10], SDK platforms and tools were refreshed through the SDK Manager or `sdkmanager --update` [11], and the shell profile was rewritten to rebuild PATH from scratch before setting ANDROID_HOME to `${HOME}/Android/Sdk` [15].
Then the repair. "Gradle was crying because of an old version unsupported to some new versions installed," the author wrote [13]. He did not edit the wrapper. "To be honest, my android application version is still quite simple, so, I fixed the issue by recreating the android directory from the flutter project root," he wrote [14]. `flutter create . --platforms=android` wrote 26 files, and the app ran again; the old directory was kept as android.old [12].
What to watch
- Whether a shipped Flutter release turns the Gradle 8.14 deprecation into a hard minimum, so the wrapper bump is required even on an older JDK.
- Whether flutter config --jdk-dir stays a supported way to hold a project on Gradle 8.14, since it is the one remedy in this error that keeps the committed wrapper where it is.
- What breaks in projects with real Android customisation once the wrapper goes to 9.1.0, which this post never tested because its android directory was regenerated from scratch.