Complete Guide to Configuring Java SDK Path in Android Studio

Core Roles of Java SDK in Android Development

The Java Development Kit (JDK) plays multiple critical roles in the Android application building process. First, it provides essential compilation tools, such as the Java compiler, used to transform Java or Kotlin source code into bytecode that can run on Android devices. Second, the JDK includes rich API libraries that developers can call from source code to implement various functionalities, though it's important to note that not all Java APIs are available on the Android platform. Additionally, the Java Virtual Machine (JVM) within the JDK is used to run the Android Studio integrated development environment and the Gradle build tool, although the JVM itself does not run on Android devices or emulators.

SDK Path Configuration Methods Across Android Studio Versions

In Android Studio 4.2 and earlier versions, configuring the Java SDK path requires navigating through the File > Project Structure > SDK Location menu to access the settings interface. The third field is labeled "JDK Location" where users can specify the JDK path for the current project. This setting only affects the currently opened project and does not impact other projects or newly created ones.

To set the default JDK path for new projects, users need to go to the File > Other Settings > Default Project Structure > SDK Location menu and specify the path in the "JDK Location" field. Once configured, all newly created projects will automatically use the specified JDK path.

In Android Studio Arctic Fox (2020.3.1), the JDK location setting was moved to a new location: Settings > Build, Execution, Deployment > Build Tools > Gradle > Gradle JDK. This change reflects Android Studio's enhanced integration with the Gradle build system, more closely coupling JDK configuration with the Gradle building process.

For earlier Android Studio versions, the configuration path is located at File > Project Structure > [Platform Settings] > SDKs. Users can choose to update existing SDK configurations to point to new directories, or define new SDK configurations and then switch project settings to use the new ones. Similarly, setting the default SDK for new projects requires navigating through File > Other Settings > Structure for New Projects > [Platform Settings] > SDKs.

Interaction Between Environment Variables and Android Studio

Environment variables play a significant role in Java SDK path resolution. Android Studio startup scripts search for JVM in a specific order: first checking the STUDIO_JDK environment variable, then the studio.jdk directory in the Android Studio distribution, followed by the JetBrains Runtime (JBR) directory, then checking JDK_HOME and JAVA_HOME environment variables sequentially, and finally looking for the java executable in the PATH environment variable.

For the Gradle building process, if Gradle is run via buttons in Android Studio, the JDK specified in Android Studio settings is used. If Gradle is run in a terminal (either inside or outside Android Studio), the JDK specified by the JAVA_HOME environment variable (if set) is used, or the java command in the PATH is utilized.

Detailed Gradle JDK Configuration

In Android Studio's Gradle settings, the Gradle JDK dropdown offers various choices: including macros such as JAVA_HOME and GRADLE_LOCAL_JAVA_HOME, JDK table entries in vendor-version format (like jbr-17), options to download JDK, add specific JDK, and locally detected JDKs from the operating system's default JDK installation directory.

The selected option is stored in the gradleJvm option in the project's .idea/gradle.xml file, and its JDK path resolution is used to run Gradle when started through Android Studio. Macros support dynamic project JDK path selection: JAVA_HOME uses the environment variable with the same name, while GRADLE_LOCAL_JAVA_HOME uses the java.home property in the .gradle/config.properties file, which defaults to JetBrains Runtime.

Java Toolchain and Compilation Configuration

The Java toolchain JDK contains the Java compiler used to compile any Java source code. This JDK also runs javadoc and unit tests during the build process. The toolchain defaults to the JDK used to run Gradle. If builds are run on different machines, using different JDK versions may lead to inconsistent build results.

To create more consistent builds, developers can explicitly specify a Java toolchain version. Doing so will: locate a compatible JDK on the system running the build; download one if no compatible JDK exists (and a toolchain resolver is defined); expose the toolchain Java APIs for calls from source code; compile Java source using its Java language version; and supply defaults for sourceCompatibility and targetCompatibility.

It's recommended to always specify the Java toolchain and ensure that the specified JDK is installed, or add a toolchain resolver to the build. The toolchain can be specified at the top level of the module's build.gradle(.kts) file:

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

Compatibility and Version Management

The sourceCompatibility property determines which Java language features are available during compilation of Java source code. It does not affect Kotlin source code. It can be specified in the module's build.gradle(.kts) file:

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
    }
}

If not specified, this property defaults to the Java toolchain version. If not using a Java toolchain, it defaults to a version chosen by the Android Gradle plugin.

The targetCompatibility and jvmTarget properties determine the Java class-format version used when generating bytecode for compiled Java and Kotlin source, respectively. Different Android versions support different Java versions. Developers can take advantage of additional Java features by increasing targetCompatibility and jvmTarget, but this might require increasing the minimum Android SDK version to ensure feature availability.

In practice, sourceCompatibility, targetCompatibility, and jvmTarget should generally use the same values. It's recommended to always explicitly specify these values or use a Java toolchain to avoid build issues.