Identifying the "4 JDKs" in Android Studio: From Launcher JVM to Toolchain

Have you ever encountered a situation where your build passes in the terminal but fails in the IDE? Or perhaps you updated Java on your system, but Android Studio seems to ignore it ?

The root cause often lies in the fact that Android Studio manages four different JDKs depending on the specific task. Confusing these can lead to "mysterious" environment issues. In this guide, we will identify each one and show you how to pinpoint them in your own environment.

🤔 Why You Need to Know the "4 JDKs"

Android Studio separates the processes that run the IDE, manage the build, and compile your source code. If these refer to different JDKs, you may run into compatibility glitches.

Let’s identify the "true identity" of each.

🤔 1. Launcher JVM (The Terminal/Entry Point)

Role: This is the JVM that initially kicks off when you run the ./gradlew script. It acts as the "starter" to wake up the heavy-lifting Gradle Daemon.

How to Identify: Run the following command in your terminal:


❯ ./gradlew -v            

------------------------------------------------------------
Gradle 9.3.1
------------------------------------------------------------

Build time:    2026-01-29 14:15:01 UTC
Revision:      44f4e8d3122ee6e7cbf5a248d7e20b4ca666bda3

Kotlin:        2.2.21
Groovy:        4.0.29
Ant:           Apache Ant(TM) version 1.10.15 compiled on August 25 2024
Launcher JVM:  21.0.10 (Eclipse Adoptium 21.0.10+7-LTS)
Daemon JVM:    Compatible with Java 21, JetBrains, nativeImageCapable=false (from gradle/gradle-daemon-jvm.properties)
OS:            Mac OS X 26.3 aarch64

Look for the line labeled Launcher JVM.

Dependent on: Your OS environment variables, specifically JAVA_HOME or your PATH setting.

🤔 2. Daemon JVM (The Build Engine)

Role: This is the "workhorse" JVM that actually performs the heavy lifting—compiling code and packaging your APK/AAB. It stays resident in memory to speed up subsequent builds.

How to Identify: Check the project-level configuration file:
gradle/gradle-daemon-jvm.properties


toolchain.vendor=JetBrains
toolchain.version=21

You can also see this in the ./gradlew -v output under Daemon JVM.

Dependent on: Gradle 8.8+ project settings.

🤔 3. IDE JDK (The Android Studio Runtime)

Role: This JVM runs the Android Studio application itself. It handles the editor UI, code completion (indexing), and IDE plugins.

How to Identify:
Mac: Android Studio > About Android Studio

Dependent on: The jbr folder bundled within your Android Studio installation directory.

🤔 4. Java Toolchain (The Compilation Target)

Role: This setting strictly defines which Java version should be used to compile your source code. It ensures that everyone on a team uses the exact same Java version for the final binary, regardless of their local IDE settings.

How to Identify: Check your app/build.gradle.kts (or build.gradle):


// build.gradle.kts

java {
  toolchain {
    languageVersion = JavaLanguageVersion.of(21)
  }
}


// build.gradle.kts

with(javaToolchains.compilerFor(java.toolchain).get().metadata) {
  logger.lifecycle("Compiler JVM: $vendor $languageVersion ($jvmVersion)")
  logger.lifecycle("$installationPath")
}

// Output:
// Compiler JVM: JetBrains 21 (21.0.10+7-b1163.108)
// /Users/jake/.gradle/jdks/jetbrains_s_r_o_-21-aarch64-os_x.2/jbrsdk_jcef-21.0.10-osx-aarch64-b1163.108/Contents/Home

Note: If this is not explicitly set, the Daemon JVM usually handles the compilation tasks by default.

🤔 Summary: Identification Checklist

Use this table as a quick reference to audit your development environment:

Final Thought
Even if your Launcher JVM is "Eclipse Adoptium" while your Daemon JVM is "JetBrains Runtime," your project will generally work fine as long as the major versions (e.g., Java 21) match.