How Android SDK Finds the JDK on Windows

By the end of this page, you will understand how Android SDK installers detect a JDK on Windows, why that detection can fail, and how to fix common problems such as missing environment variables, incorrect paths, and 32-bit vs 64-bit mismatches.

The core concept behind this problem is toolchain detection.

Programming tools often depend on other tools being installed first. In this case, parts of the Android development setup expect a working Java Development Kit (JDK), not just Java in general. If the installer cannot detect the JDK correctly, it stops even if Java is actually installed.

JDK vs JRE

A common source of confusion is the difference between:

• JRE (Java Runtime Environment): lets you run Java programs
• JDK (Java Development Kit): includes the JRE plus development tools like javac

Android development tools historically required the JDK, because they needed to compile Java code, not only run it.

Why detection fails

On Windows, installers usually detect the JDK by checking one or more of these:

• standard installation folders such as C:\Program Files\Java\...
• Windows Registry entries created by the JDK installer
• environment variables such as JAVA_HOME
• whether commands like java and javac are available in PATH

If any of these are missing, inconsistent, or point to the wrong version, the installer may incorrectly report that no JDK is installed.

Why this matters

This is not just an Android SDK issue. Many developer tools depend on:

• correct installation paths
• correct environment variables
• compatible versions
• matching system architecture

Learning how dependency detection works helps you troubleshoot not only Java and Android setup, but also tools like Maven, Gradle, Node.js, Python, and compilers.

Think of the Android SDK installer like a delivery driver trying to find a house.

The JDK may already exist, but the driver needs the correct address.

• The JDK installation folder is the house
• The Registry and environment variables are the address book
• The PATH variable is the road map
• The installer is the driver

If the house exists but the address book is wrong or incomplete, the driver says, "I can't find it," even though it is there.

So the problem is often not that Java is missing, but that Windows or the installer does not know where to look.

The most useful syntax here is not Android code, but Windows command-line checks and environment variable setup.

Check whether Java is installed

Open Command Prompt and run:

java -version
javac -version

Expected result:

• java -version confirms Java can run
• javac -version confirms the JDK is installed, because javac comes from the JDK

Check common install locations

Typical JDK path on Windows:

C:\Program Files\Java\jdk1.6.0_23

Set JAVA_HOME temporarily

In Command Prompt:

set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_23
set PATH=%JAVA_HOME%\bin;%PATH%

Then test again:

javac -version

Set JAVA_HOME permanently

A typical value would be:

JAVA_HOME=C:\Program Files\Java\jdk1.6.0_23

And add this to PATH:

Use this small troubleshooting flow.

java -version
javac -version
echo %JAVA_HOME%

Suppose you get:

• java -version works
• javac -version fails
• JAVA_HOME is empty

Step-by-step meaning

1. java -version

If this works, Java runtime is available somewhere in your PATH.

That does not guarantee the JDK is installed.

2. javac -version

If this fails, one of these is true:

• the JDK is not installed
• the JDK is installed but its bin folder is not in PATH
• the installer wrote incomplete registry or environment information

3. echo %JAVA_HOME%

If this prints nothing, then JAVA_HOME is not set.

Some installers can still work without JAVA_HOME, but many tools behave better when it is set correctly.

This concept appears in many real development situations.

Mobile development setup

Android tools may require:

• a JDK
• Gradle
• Android SDK components
• environment variables

If one dependency is not discoverable, the whole setup fails.

Build tools

Tools like Maven and Gradle often depend on JAVA_HOME.

If JAVA_HOME points to the wrong directory, builds can fail even when Java is installed.

CI/CD pipelines

On build servers, you often must configure:

• exact JDK version
• JAVA_HOME
• correct PATH

Otherwise automated builds fail with “Java not found” errors.

Developer onboarding

When a new developer clones a project, setup scripts may assume Java is installed correctly. Knowing how detection works helps fix local environment issues quickly.

Legacy software support

Older tools sometimes expect specific folder names, registry keys, or 32-bit Java installations. Troubleshooting these issues is common when maintaining older applications.

In real projects, developers rarely rely only on a GUI installer. They verify and enforce the environment explicitly.

Common patterns

Guard checks in scripts

Build scripts often check Java before doing anything else.

javac -version
if errorlevel 1 (
  echo JDK not found. Please set JAVA_HOME correctly.
)

This is a guard clause: fail early if a required dependency is missing.

Using JAVA_HOME

Many projects standardize on JAVA_HOME so all tools use the same JDK.

Example convention:

JAVA_HOME=C:\Program Files\Java\jdk1.8.0_202

Explicit configuration

Teams often document setup steps such as:

• install a supported JDK version
• set JAVA_HOME
• add %JAVA_HOME%\bin to PATH
• verify with java -version and javac -version

Validation scripts

Real codebases may include setup scripts that validate environment configuration before builds or tests run.

Version compatibility checks

1. Installing the JRE instead of the JDK

Broken assumption:

I installed Java, so Android SDK should work.

Why it fails:

• the JRE is not enough for development
• the Android toolchain usually needs javac

How to avoid it:

• install the JDK, not only the JRE
• verify with javac -version

2. Setting JAVA_HOME to the wrong folder

Broken example:

JAVA_HOME=C:\Program Files\Java\jdk1.6.0_23\bin

Why it fails:

• JAVA_HOME should point to the JDK root, not the bin folder

Correct:

JAVA_HOME=C:\Program Files\Java\jdk1.6.0_23

3. Forgetting to update PATH

Broken situation:

• JDK is installed
• JAVA_HOME is set
• but still cannot be found

Quick checks

java -version
javac -version
echo %JAVA_HOME%

Correct JDK setup on Windows

• Install the JDK, not only the JRE
• Set:

JAVA_HOME=C:\Program Files\Java\jdk1.6.0_23

• Add to PATH:

%JAVA_HOME%\bin

Important rules

• JAVA_HOME points to the JDK root folder
• Do not set JAVA_HOME to the bin folder
• javac must work for most Java development tools
• Older Android SDK installers may have 32-bit/64-bit detection issues

Common fix order

1. Verify JDK install folder exists
2. Run javac -version
3. Set JAVA_HOME
4. Add %JAVA_HOME%\bin to PATH
5. Restart Command Prompt
6. Retry the installer

If it still fails

Why does the Android SDK say the JDK is missing when Java is installed?

Because Java being installed does not always mean the JDK is installed or detectable. The installer may find a runtime but not the compiler tools it needs.

How can I tell whether I installed the JDK or only the JRE?

Run:

javac -version

If javac is not found, you likely do not have a usable JDK setup.

What should JAVA_HOME point to?

It should point to the JDK root folder, for example:

C:\Program Files\Java\jdk1.6.0_23

Not the bin subfolder.

Do I need both JAVA_HOME and PATH?

Often yes. JAVA_HOME helps tools locate the JDK, and PATH lets you run java and javac directly from Command Prompt.

Can 64-bit Windows cause JDK detection problems?

Yes. Some older installers had trouble detecting certain 64-bit Java installations or expected 32-bit components.

Should I reinstall Java if the installer still cannot find it?

• Java Development Kit (JDK) — The main dependency the Android tools need.
• Java Runtime Environment (JRE) — Useful for understanding why running Java is different from compiling Java.
• Environment variables — Important because tools use variables like JAVA_HOME and PATH for detection.
• PATH variable — Explains how Windows finds executables such as java and javac.
• Command Prompt troubleshooting — Helps verify whether tools are installed and accessible.
• Build tools — Tools like Gradle and Maven also rely on correct Java configuration.
• 32-bit vs 64-bit architecture — Relevant when older installers fail to detect modern installations.
• Toolchain setup — The broader concept of configuring multiple dependent development tools correctly.