Development of mobile applications for the Android platform is impossible without proper configuration of the tools. The central element of the developer ecosystem is Android SDK (Software Development Kit) - a set of libraries, emulators and command line utilities. However, after downloading the installer or setting up the IDE, many beginners and even experienced programmers have a logical question about the physical location of these files on the hard drive.

Understanding this where the Android SDK is installedis critical not only for freeing up space on the system partition, but also for the correct operation of project builders such as Gradle. Incorrect paths often cause compilation errors when the development environment simply cannot find the necessary platforms or build tools. In this article, we will analyze in detail the standard directories for various operating systems and how to change them.

Knowing the directory structure will allow you to manually manage API versions, clear the cache and optimize workflow. Let's move from theory to practice and find out exactly where this voluminous data package is hidden on your computer.

Standard installation paths in Windows

In the Windows operating system, the location of the files depends on the exact method you installed: through the official SDK Tools installer or in conjunction with the integrated development environment Android Studio. By default, if you did not change the settings during installation, the system will offer a hidden directory in the user profile.

Most often the path looks like this: C:\Users\UserName\AppData\Local\Android\Sdk. Please note that the folder AppData is hidden by default, so to go directly to it you need to turn on show hidden items in Explorer or enter the path manually in the address bar. This location was chosen by Google developers to isolate user-specific tools from system files.

However, if you installed only Command-line tools or used older versions of the installer, the path may differ. In such cases, the location is often found in the root of the C: C:\Android\android-sdkdrive. This structure was popular in early versions of documentation and is still used in some corporate environments to simplify access to tools for all users of the machine.

โš ๏ธ Attention: The folder AppData can occupy tens of gigabytes. When cleaning the disk with system utilities, be careful not to accidentally delete critical SDK components, which will cause your projects to not work.

You can use the settings menu to quickly check the current location in the environment Android Studio . Go to File โ†’ Settings โ†’ Appearance & Behavior โ†’ System Settings โ†’ Android SDK. At the top of the window you will see the "Android SDK Location" field, which indicates the active directory. This is the most reliable way to find out the truth if you donโ€™t remember where you installed the package initially.

๐Ÿ“Š Where do you prefer to store the Android SDK?
In the user folder (AppData)
On a separate drive (D:\SDK)
In the root of the system drive (C:\Android)
I donโ€™t know where I have it

SDK location in macOS and Linux

Users of Unix-like systems are faced with a different file structure. On macOS, when installed via Android Studio, the standard path is usually in the user's home directory. It looks like /Users/UserName/Library/Android/sdk. As is the case with Windows, the folder Library may be hidden from normal viewing in the Finder, so to navigate, use the keyboard shortcut Cmd + Shift + G and enter the path.

In a Linux environment, the situation is even more complicated is variable, as it depends on the distribution and installation method (via a repository, snap package or manual archive). The most common path for a custom installation is /home/Username/Android/Sdk. If you installed tools for all users of the system, they can be located in /opt/android-sdk or /usr/lib/android-sdk.

You can determine the exact location in Linux through the terminal by checking the environment variables. Often the path is specified in shell configuration files, such as .bashrc or .zshrc. Using the command echo $ANDROID_HOME or echo $ANDROID_SDK_ROOT will instantly display the current path if the variables were exported correctly.

๐Ÿ’ก

On macOS, the Library folder is hidden by default. To quickly get to it, press Cmd+Shift+G in the Finder and enter ~/Library/Android/sdk.

It is important to note that in recent versions of macOS, access rights to system folders have become stricter. If you decide to move the SDK to a system directory other than your home, you may need to use sudo to manage files, which is not recommended for security reasons and ease of updating.

Manually changing the SDK installation path

The system disk is often limited in space, especially on laptops with small SSD drives. A reasonable solution is to transfer the heavy one Android SDK to another logical partition or an external fast drive. The procedure for changing the path does not require reinstalling the entire package, just move the files and update the settings.

First close all instances Android Studio and emulators. Then find the current SDK folder and move it entirely to the new desired location, for example D:\Dev\Android\Sdk. Make sure that the copying process is completed successfully and all subfolders (platforms, build-tools, emulator) are saved.

After the move, you need to inform the development environment about the new coordinates. Launch the IDE and go to Settings (Preferences on Mac or Settings on Windows). In the Appearance & Behavior โ†’ System Settings โ†’ Android SDK section, change the path in the "Android SDK Location" field to a new one. Click "Apply" and the studio will scan the directory, pulling up all installed components.

โ˜‘๏ธ SDK transfer checklist

Done: 0 / 5

โš ๏ธ Attention: When transferring to another drive, make sure that there are no Cyrillic characters or spaces in the path. Some command line tools (for example, older versions of the NDK) may not handle such paths correctly, causing build errors.

If you work in a team or use CI/CD systems, make sure that the path to the SDK is not hardcoded in local project configuration files, such as local.properties. This file is generated automatically, but when the path is changed, its contents must be updated, otherwise the assembly on other machines may be gagal.

Setting up environment variables

To work with SDK tools from the terminal or command line without specifying the full path to each executable file, you need to set up system variables. This allows you to run commands like adb or avdmanager from any project directory.

The key variables are ANDROID_HOME or ANDROID_SDK_ROOT. They should point to the root SDK folder. In addition, you need to add the paths to the subdirectories platform-tools and tools (or cmdline-tools) to the system variable Path (in Windows) or PATH (in macOS/Linux).

An example of correctly setting paths to add to the Path variable in Windows:

%ANDROID_HOME%\platform-tools

%ANDROID_HOME%\tools\bin

%ANDROID_HOME%\emulator

In Linux and macOS, these lines are added to the shell configuration file. For example, for bash it will look like this:

export ANDROID_HOME=$HOME/Android/Sdk

export PATH=$PATH:$ANDROID_HOME/emulator

export PATH=$PATH:$ANDROID_HOME/platform-tools

export PATH=$PATH:$ANDROID_HOME/tools/bin

Why two variables ANDROID_HOME and ANDROID_SDK_ROOT?

Previously, only ANDROID_HOME was used. However, in new versions of the tools, Google recommended using ANDROID_SDK_ROOT for greater flexibility. Both variables are currently supported, and having one of them is usually sufficient for most tools to work, but for full compatibility with older scripts it is better to set both to point to the same path.

After making changes, be sure to restart your terminal or command line for the new values โ€‹โ€‹to take effect. You can check your success by entering the command adb version. If you see the Android Debug Bridge version number in response, then the configuration is correct.

Folder structure inside the Android SDK

Inside the SDK directory there are many subfolders stored, each of which is responsible for a specific aspect of development. Understanding their purpose will help you not to delete unnecessary things when cleaning up space and to correctly connect the necessary components.

Below is a table of the main directories and their contents:

Folder Purpose Is it possible delete?
platforms Contains files of specific Android versions (API levels) for which you compile applications. Yes, if you do not use these API versions in projects.
build-tools Compilation tools (dx, aapt, zipalign). Versions must meet the requirements of the project. Caution. Delete only old versions, leaving the current one.
emulator Device emulator files and system images for virtual devices. Yes, but the emulator will stop working without reinstallation.
platform-tools Contains utilities adb i fastboot. Usually one version for all APIs. No, this is a critical component for debugging.
system-images Operating system images to run in the emulator. They take up the most space. Yes, if you are not using an emulator for specific versions of Android.

Particular attention should be paid to the folder system-images. It is this that often grows to enormous sizes, since each downloaded emulator image weighs several gigabytes. If you prefer to test applications on real devices, this folder can be safely cleared through the SDK Manager.

๐Ÿ’ก

The most voluminous content of the SDK is the emulator system images (system-images). Removing them will free up gigabytes of space without harming the compilation of applications.

Also in the root there may be a folder extrascontaining additional drivers (for example, Google USB Driver) or support libraries. You should only delete them if you know for sure that they are not used in your build.gradle files.

Frequent problems with paths and their solutions

One โ€‹โ€‹of the most common errors is a mismatch between the paths in the project configuration files and the actual location of the SDK on the disk. This often happens when cloning repositories from GitHub, where the absolute path of the author of the original code is written in the file. local.properties the absolute path of the author of the original code is specified.

When opening such a project Android Studio it will give the error "SDK not found". The solution is simple: delete the file local.properties from the project root. At the next synchronization, Gradle will automatically generate a new file with the correct path taken from the global settings of your IDE.

Another problem arises when updating the development environment itself. Sometimes, after a major update, Studio resets its settings or loses links to tools if they were installed in a non-standard location. In this case, the menu item helps File โ†’ Invalidate Caches / Restart, which forcibly rescans the file system.

โš ๏ธ Attention: If you use several versions of Android Studio in parallel (for example, stable and Canary), make sure that they refer to the same SDK directory. This will save disk space and prevent duplication of platforms and tools.

It is also worth remembering that the access rights to the SDK folder must allow writing. If you installed the SDK in a protected system folder (for example app Files on Windows) without administrator rights, the component update process through the SDK Manager will fail. In such cases, it is better to move the SDK to the user directory.

Where is the local.properties file located and why do you need it?

The file local.properties is located in the root folder of each Android project. It contains local settings specific to the developer's machine, the main one of which is the path to the SDK (sdk.dir). This file should not go into version control (Git), since the paths differ from developer to developer.

Is it possible to install the Android SDK on a flash drive or external SSD?

Technically it is possible, but not recommended for active development. The read/write speed of external drives (especially USB 2.0) may not be sufficient for quick compilation and operation of the emulator, which will lead to a significant slowdown. In addition, if the disk is disconnected, building projects will become impossible.

What to do if after changing the path the emulator does not start?

The emulator stores data about virtual devices (AVD) separately from the SDK binaries, usually in a folder .android/avd in the user profile. When migrating the SDK, the paths to the system images may become confusing. Try re-creating the virtual device through AVD Manager or check the environment variable ANDROID_AVD_HOME.

How can you learn how much space the Android SDK takes up?

In Windows, right-click on the SDK folder in Explorer and select "Properties". On macOS, highlight the folder in the Finder and click Cmd + I. On Linux, use the command du -sh /path/to/sdk in the terminal. This will show the actual size of all nested components.

Is it necessary to install the entire SDK if I'm just learning?

No. Through the SDK Manager, you can select a minimum set: one version of Platform Tools, one version of Build Tools and one system image for the emulator. This will save space and time on the initial download, purchasing the necessary components as you learn new versions of Android.