Introduction

When Android SDK Manager refuses to install components, the root cause is usually mundane: bad permissions, blocked network access, an invalid SDK path, unaccepted licenses, or a corrupted package cache. The difficult part is that Android Studio often reports the failure with a vague “package not installed” message.

The fastest fix is to stop guessing and verify the SDK location, the command-line tools, the network path to Google repositories, and the local filesystem state. Once those are checked, most installation failures become obvious.

Start With the Command-Line Tool

Android Studio is convenient, but the sdkmanager CLI gives clearer errors. First confirm that the command-line tools are installed and that you are pointing at the correct SDK root.

export ANDROID_SDK_ROOT="$HOME/Library/Android/sdk"
"$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager" --list

If that command fails, the problem is often the SDK path itself, not the package you were trying to install.

On Windows, the same idea applies, but use the sdkmanager.bat path inside the SDK directory.

Accept Licenses Explicitly

A very common failure is an unaccepted license. Android Studio sometimes hides this behind a generic install error, while the CLI reports it directly.

"$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager" --licenses

Accept the pending licenses, then retry the install:

"$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager" "platform-tools" "platforms;android-35"

If this succeeds in the terminal but fails in the IDE, the IDE is probably pointing at a different SDK directory.

Check Permissions and Disk State

The SDK manager needs write access to the SDK folder and enough free disk space to unpack archives. On macOS or Linux, verify the directory ownership and permissions:

ls -ld "$ANDROID_SDK_ROOT"
ls -ld "$ANDROID_SDK_ROOT/platforms"

If the SDK directory is owned by another user or was created with sudo, Android Studio may download packages but fail during extraction.

Also inspect partially downloaded or corrupted package directories. A broken temp or incomplete package folder can cause repeated install failures until it is removed.

Network and Proxy Problems

If you are on a corporate network, proxy settings are often the real issue. Android Studio may need explicit HTTP proxy configuration even when the rest of the system has internet access.

The usual symptoms are:

• package download starts and stalls
• repository refresh never finishes
• some components install while others fail

In Android Studio, check the HTTP proxy settings and make sure security software is not intercepting or blocking Google download endpoints. If command-line downloads also fail, test from the shell with a simple request or by retrying sdkmanager --list.

Verify the Repository Metadata Path

Older setups sometimes fail because the local SDK metadata or cached repository state is stale. When that happens, update the command-line tools first, then retry the missing package.

"$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager" --update

If the cache looks corrupted, close Android Studio and remove only obviously temporary or broken cache content, not the whole SDK tree unless you are ready to reinstall everything.

A Minimal Known-Good Install Flow

This shell sequence is a good baseline on a clean machine:

1export ANDROID_SDK_ROOT="$HOME/Library/Android/sdk"
2mkdir -p "$ANDROID_SDK_ROOT"
3"$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager" --licenses
4"$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager" --update
5"$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager" \
6  "platform-tools" \
7  "build-tools;35.0.0" \
8  "platforms;android-35"

If this path works, your environment is healthy and the remaining issue is probably Android Studio configuration rather than the SDK packages themselves.

When Reinstallation Is Reasonable

Reinstalling the SDK is a valid last resort, but it should be the last resort. If you delete the whole SDK before checking licenses, proxies, and permissions, you often end up with the same problem on a fresh directory.

Use reinstallation when:

• the SDK directory is badly corrupted
• multiple core tools are missing
• Android Studio and sdkmanager disagree about the SDK structure

Even then, keep the diagnosis in mind so the same failure does not repeat.

Common Pitfalls

The most common mistake is having Android Studio point to one SDK directory while the terminal and environment variables point to another. That makes installs appear random.

Another mistake is running one install with sudo and later trying to update the same SDK as a normal user. Mixed ownership causes repeated permission failures.

People also ignore license prompts because the IDE message is vague. Running sdkmanager --licenses is often the fastest fix.

Finally, do not assume a network issue always means “no internet.” Proxies, SSL interception, and firewall rules can break SDK downloads even when browsing the web works.

Summary

• Use sdkmanager directly to get clearer errors than Android Studio usually provides.
• Confirm ANDROID_SDK_ROOT and the actual SDK path used by the IDE are the same.
• Accept licenses explicitly with sdkmanager --licenses.
• Check directory ownership, write permissions, free space, and broken partial downloads.
• Treat full SDK reinstallation as a last step, not the first one.