EErrorHarbor
Error Library

Android SDK Location Not Found: Fix sdk.dir in local.properties

SDK location not found means the Android build cannot resolve a usable Android SDK location in the environment where Gradle is running. First prove the SDK exists on that machine/runner, then identify whether this build should use project-local sdk.dir or an environment-provided SDK location. Do not install random SDK packages or edit Gradle dependencies until location discovery works.

Android Studio · GradleWindows · macOS · LinuxLast reviewed Sep 27, 2026
🎯 You’re likely in the right place if:
Gradle or Android Studio reports SDK location not found.The project was cloned, moved to another machine, or opened outside Android Studio.The Android SDK is installed but the project cannot locate it.
Choose the path that matches what you see
Android Studio shows an SDK pathUse that exact path for sdk.dir on this machine.
Project was cloned from another computerReplace the stale machine-specific local.properties value; do not reuse someone else’s absolute path.
local.properties is missingCreate it only after confirming the local SDK directory.
Failure is CI/headless onlyInspect the runner's SDK installation and environment. Prefer ANDROID_HOME for the SDK location; ANDROID_SDK_ROOT is deprecated.
SDK path resolves, next error says a platform/build-tools package is missingStop changing sdk.dir. SDK discovery succeeded; diagnose the missing SDK component separately.
Windows path was copied into local.propertiesCheck Java-properties path syntax/escaping instead of assuming the visible Windows path was parsed literally.
Difficulty: Easy–ModerateRisk: Low first
🔎 First check — prove the SDK exists in the failing environment

Find the Android SDK on the same machine, container or CI runner that reports the error. For a local Android Studio build, compare SDK Manager with the project root local.properties. For CI/headless builds, inspect the runner's configured SDK environment rather than copying a developer workstation path.

sdk.dir=/absolute/path/to/Android/Sdk

Verify: The path exists inside the failing environment and is an Android SDK root (for example it contains SDK component directories such as platform-tools or platforms). Only then choose the appropriate way to expose that path to the build.

Did sdk.dir point to the wrong or missing path?

Common SDK locations to check

W
Windows
Android Studio commonly uses %LOCALAPPDATA%\Android\Sdk. Confirm it in SDK Manager instead of assuming.
M
macOS
A common location is ~/Library/Android/sdk.
L
Linux
A common location is ~/Android/Sdk.

Treat these as common defaults, not proof. Android Studio’s SDK Manager is the authoritative location on your machine.

ADSENSE · reserved slot after the first useful step

Why this happens

Android build tooling needs to discover an installed SDK root. For local projects, local.properties can hold machine-local sdk.dir. Automated/headless environments commonly expose the SDK through their environment configuration. These are location mechanisms, not substitutes for actually installing the SDK or its required components.

Diagnose before changing more

1
Does the SDK actually exist?
Use Android Studio SDK Manager or your known SDK location before editing paths.
2
Is local.properties from another computer?
Absolute SDK paths are machine-specific and commonly break after cloning or moving projects.
3
Is local.properties missing?
Create it in the project root only after you know the correct local SDK path.
4
Local workstation or CI/container?
Do not copy a host/developer absolute path into a runner/container where that filesystem path does not exist.
5
Is the path parsed correctly on Windows?
local.properties uses Java-properties syntax. Prefer a representation known to parse correctly, such as forward slashes in the Windows path, rather than blindly pasting unescaped backslashes.
6
Did the error change to missing platform/build-tools/compileSdk?
That proves SDK location discovery progressed. Diagnose the newly named component/version instead of continuing to edit sdk.dir.

Fix #2 — write the correct sdk.dir for this machine

Set sdk.dir in the root local.properties file to the actual SDK directory. Use the path format appropriate for your operating system.

# macOS example sdk.dir=/Users/you/Library/Android/sdk # Windows example using forward slashes sdk.dir=C:/Users/you/AppData/Local/Android/Sdk
🟡 Before changing configuration: Do not commit another developer’s absolute SDK path into source control.

Verify: Sync or rerun the failed Gradle task. If the build moves past “SDK location not found,” the path issue is fixed even if a new, unrelated build error appears.

Did Fix #2 work?

Fix #3 — CI/headless: expose the SDK in the runner, not a developer path

For a CI runner, container or other headless environment, first ensure the SDK is installed/mounted in that environment and set its supported SDK-location environment configuration (normally ANDROID_HOME) to that runner-side SDK root. Do not generate a local.properties containing a workstation path unless your build intentionally manages a runner-local file.

./gradlew tasks
🟡 Keep it reversible: On Windows, run the Gradle wrapper command appropriate for your shell, such as gradlew.bat tasks.

Verify: The Gradle wrapper should start configuration without the SDK-location error. On CI, verify the runner sees the intended SDK path before debugging project dependencies.

Did Fix #3 work?

What not to do

Do not commit a personal absolute sdk.dir path to source control.Do not put arbitrary custom project settings in local.properties; Android reserves it for specific local build properties.Do not set deprecated ANDROID_SDK_ROOT as a second competing SDK location when ANDROID_HOME already points to the intended SDK unless legacy tooling explicitly requires it.Do not copy a host/workstation sdk.dir into Docker or CI unless that exact path exists inside the failing environment.Do not keep editing sdk.dir after Gradle has moved on to a missing platform, build-tools, compileSdk or other component error.Do not blindly paste Windows backslashes into local.properties without accounting for Java-properties parsing; use a path representation that is parsed as intended.

Still seeing the error?

If the intended SDK root exists and the build still reports the same location error, compare the path as seen by the actual Gradle process: project root/local.properties for local builds, environment/mounts for CI or containers, and filesystem permissions where relevant. If the error changes to a named SDK component/version, SDK location is no longer the failing stage.

Before escalating, capture:the exact Gradle/Android Studio error textthe SDK path shown by Android Studio SDK Managerthe current sdk.dir line with your username/path redacted if sharing publiclywhether the failure is local, CI-only, container-only, or bothANDROID_HOME value in the failing environment, if usedfor Windows, the exact sdk.dir syntax with personal path segments redactedthe first new error if SDK location resolution succeeds

References and related guides

checkDebugAarMetadata FailedIf an AAR declares a compileSdk, AGP or SDK-extension requirement →Android Resource Linking Failed (AAPT2)When the build reaches resources, read the first concrete AAPT2 error →Android Developers: Configure your buildOfficial description of local.properties and sdk.dir →Android Developers: Android build structureProject structure and machine-local SDK configuration →Android Developers: Environment variablesANDROID_HOME and deprecated ANDROID_SDK_ROOT behavior →

Still stuck? Ask the community

Share your operating system, software version, exact error text, and which fix you already tried. Another reader may have seen the same setup.

Keep it safe: never post passwords, API keys, access tokens, recovery codes, license keys, private URLs, or confidential logs.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…