You have Android Studio installed, java -version works, and the Expo Android build still fails before compiling anything. Depending on what Gradle tried, you see one of two messages. The first is when no matching JDK was found:

Cannot find a Java installation on your machine (Windows 11 …) matching: {languageVersion=17, …}. …

The second is when Gradle tried to download one and failed:

Unpacked JDK archive does not contain a Java home: C:\Users\<you>\…\.gradle\…\jdks\…

Both messages are quoted from Gradle 9.3.1's source code. We didn't keep our raw log, so the parts shown as … and the path are placeholders; in our case it was the second message.

Both come from the same mismatch: the Java that runs Gradle isn't the Java that React Native's Gradle plugins ask to be compiled with. Here's why, and how to fix it by hand.

Two different JDKs

Gradle uses Java in two roles:

  1. The JDK that runs Gradle. From a terminal it's JAVA_HOME, or the java on your PATH if JAVA_HOME isn't set. From Android Studio it's the JDK in the IDE settings, by default the bundled JetBrains Runtime (JBR). Gradle 9 needs Java 17 to 27 here, so a JBR 21 is fine.
  2. The toolchain JDK. This is the compiler a build declares it needs. React Native 0.86's Gradle plugins declare kotlin { jvmToolchain(17) }. Gradle then has to find a JDK whose major version is exactly 17. A JDK 21 doesn't count.

So a Windows PC with only Android Studio's JBR 21 can run Gradle fine and still have no Java 17 for the plugins.

When that happens, Gradle tries to auto-detect a JDK 17 in the usual places: operating-system locations, JAVA_HOME and a few package managers. If it finds none, it tries to auto-provision one. The React Native plugin build applies the foojay toolchain resolver, so Gradle downloads a JDK 17 archive and unpacks it into <GRADLE_USER_HOME>\jdks.

What went wrong for us

On our first configuration of an Expo SDK 57 project, Gradle was running on JBR 21, and no JDK 17 was installed in the standard vendor folders. Foojay downloaded a complete Temurin 17 archive (190 MB) into a Gradle home that sat about 190 characters deep. Gradle then didn't recognise the unpacked folder as a Java home.

Our best explanation is Windows' 260-character path limit: the JDK's own internal paths, added to a 190-character root, go past it. The same JDK had unpacked correctly into the default, shorter %USERPROFILE%\.gradle\jdks a week earlier. That's a strong hypothesis, but we haven't reproduced it in isolation.

Either way, depending on a download in the middle of a release build is fragile. The robust fix is to install JDK 17 once and tell Gradle where it is.

The manual fix

1. Install a full JDK 17

Install a JDK, not a JRE: the toolchain needs javac. Expo's Windows setup guide uses Microsoft's build:

choco install -y microsoft-openjdk17

The installers from Eclipse Temurin, Azul Zulu or Amazon Corretto work too. Install into the default Program Files folder, which is short and standard.

2. Check what Gradle sees

From your project's android folder:

.\gradlew.bat -q javaToolchains

This lists every JDK Gradle detected and where it found it. If a 17.x is listed, the next build should pick it up on its own.

3. Point Gradle at it explicitly (recommended)

Auto-detection depends on how the JDK was installed. To leave nothing to chance, add these lines to your user Gradle properties, %USERPROFILE%\.gradle\gradle.properties, so they apply to every project and never end up in Git:

org.gradle.java.installations.paths=C:/Program Files/<vendor>/<your-jdk-17-folder>
org.gradle.java.installations.auto-download=false
  • Replace the placeholder with the exact folder of your installation, copied from Explorer: the one containing bin\java.exe and bin\javac.exe. Gradle doesn't look inside nested folders.
  • Use forward slashes, or escape every backslash (C:\\Program Files\\…), because .properties files treat \ as an escape character.
  • auto-download=false turns a missing JDK into an immediate, clear error instead of a 190 MB download halfway through the build.

These are the same properties WinBuild writes for every build (see below). Written by hand as above, they follow Gradle's documentation, but we haven't tested this exact file on its own.

4. Alternative: run Gradle on JDK 17 too

The simplest setup of all: set JAVA_HOME to the JDK 17 folder, so the same JDK runs Gradle and is found as the toolchain. Gradle 9 accepts Java 17 as its runtime. If you build from Android Studio, also select that JDK as the Gradle JDK in the IDE settings, so the terminal and the IDE agree.

5. If you rely on auto-download

If you want to keep auto-download, make sure the Gradle home has a short path, for example $env:GRADLE_USER_HOME = "C:\gh". Delete any half-unpacked JDK left in its jdks folder before trying again.

How WinBuild handles it

WinBuild doesn't download JDKs, and it doesn't let Gradle download one:

  • winbuild doctor --tools reports whether a usable JDK 17 is present (JAVA17_TOOLCHAIN_DETECTED or JAVA17_TOOLCHAIN_MISSING) before you start a build.
  • Explicit selection. It looks in %USERPROFILE%\.gradle\jdks and in the standard vendor folders (Eclipse Adoptium, Microsoft, Java, Zulu, Amazon Corretto, BellSoft), or uses the WINBUILD_JDK17_HOME you set. A candidate counts only if its release file says 17.x, it has both java.exe and javac.exe, and java -version really reports 17. The highest 17.x wins.
  • No surprises inside Gradle. WinBuild writes the selected path into the Gradle home of that build attempt, with auto-detection and auto-download turned off. That's the same three properties as step 3, but your project, its plugins and jvmToolchain are never modified.
  • A clear stop. With no JDK 17, the build stops with JAVA17_TOOLCHAIN_REQUIRED before Gradle starts, instead of failing minutes in.

With Temurin 17 selected this way, the same Expo SDK 57 configuration that had failed succeeded in 302 seconds, and no JDK was downloaded.

Sources

External sources consulted on 20 October 2026. Figures about WinBuild come from our own build records.

Private alpha

Building Expo Android releases on Windows?

WinBuild is in private alpha. Testers get the package directly and help validate different machines and Expo projects.

Request alpha access →No checkout yet · direct founder feedback

← All articles