Mukesh@gmail.com
Introduction
One thing nobody warns you about when you first start Android development is how quickly the SDK folder grows. You install Android Studio, let it download a few things automatically, and within a few weeks your SSD is showing a 20 to 30 GB chunk dedicated to Android alone. That is not unusual at all. In fact, it is very common.
The Android SDK Manager is the tool responsible for all of that. It downloads, installs, and manages every SDK component on your machine. The problem is that most developers never revisit it after the initial setup. Old platforms pile up, outdated build tools stay installed, and duplicate system images keep sitting on the drive even when no one is using them.
This guide is about using the Android SDK Manager intentionally — understanding what each package is, what you actually need, and what you can safely remove to recover significant disk space without breaking anything. Every recommendation here is based on practical experience, not just theory. If your development machine is running low on storage, this is a good place to start.
Why the Android SDK Gets So Large Over Time
The Android SDK Manager is designed to let you install as many packages as you want. It does not push you to clean up old ones. That design makes sense for flexibility, but it also means storage accumulates without you realizing it.
There are a few specific reasons the SDK folder expands over time.
Every time a new Android version releases, developers install the new platform. But the old platforms often stay installed because nobody thinks to remove them. By 2026, if you have been developing for a few years, you might have platforms for Android 10, 11, 12, 13, 14, and 15 all sitting in your SDK folder — even if your apps only need to support Android 10 and above with a single compileSdk targeting 35.
System images are the biggest storage consumers. A single system image for the Android emulator can take 1.5 to 3 GB. If you have multiple images installed — different API levels, different ABIs — those add up to 10 GB or more without much effort.
Build-tools versions also accumulate. Each time a project specifies a slightly different buildToolsVersion, you install another copy. Older versions rarely get cleaned up.
This is all managed through the Android SDK Manager, which means it is also where all the cleanup happens.
Opening the Android SDK Manager
Before making any changes, you need to know how to access the Android SDK Manager in the two main ways developers use it.
Inside Android Studio, go to the top menu and click Tools. Then select SDK Manager. A window opens with two tabs: SDK Platforms and SDK Tools. This is the graphical interface to the Android SDK Manager and shows you everything currently installed and available.
From the command line, the Android SDK Manager is accessed through the sdkmanager binary, located at:
android-sdk/cmdline-tools/latest/bin/sdkmanager
To see everything installed on your machine:
sdkmanager –list_installed
To see all available packages including ones not yet installed:
sdkmanager –list
Both interfaces give you full control. The graphical version in Android Studio is easier for visual inspection. The command line is faster when you know exactly what you want to remove or install.
Understanding Which SDK Packages Are Actually Essential
To use the Android SDK Manager to clean up effectively, you first need to understand which packages are genuinely required and which ones are just leftovers.
Here is the honest breakdown of what a typical Android developer actually needs.
One Android SDK Platform matching your compileSdk version. If your projects all target API 35, you only need platforms;android-35 installed. You do not need every platform back to API 21.
One version of Build-Tools that matches your buildToolsVersion setting. Check your app-level build.gradle to see what version is specified. You only need that one version, unless you actively work on multiple projects with different requirements.
Platform-Tools, which includes ADB. This should always be kept updated. It is a single package and takes minimal space.
The Android Emulator binary, if you use virtual devices for testing. This is one package and is required for any emulator to work.
System images only for the emulators you actually use. If you created a Pixel 6 emulator running Android 14 and that is the only emulator you run, you only need that one system image installed.
That is genuinely the complete list for most developers. Everything beyond that is either optional or redundant. The Android SDK Manager makes it easy to uninstall the extras once you know what to look for.
How to Identify What Is Taking Up the Most Space
Before removing anything from the Android SDK Manager, it is worth finding out exactly what is consuming the most storage. That way you target the biggest wins first.
On macOS and Linux, open a terminal and navigate to your SDK folder. Run:
du -sh android-sdk/platforms/*
This shows you the size of each installed platform folder. Repeat for other directories:
du -sh android-sdk/build-tools/* du -sh android-sdk/system-images//
On Windows, open File Explorer and navigate to your SDK folder (usually at C:\Users\YourName\AppData\Local\Android\Sdk). Right-click on each subfolder and check Properties to see its size.
Most developers are surprised to find that system-images is by far the largest folder. A single x86_64 system image with Google Play Services can be 2.5 to 3.5 GB. Having four or five of them installed adds up to more storage than everything else in the SDK combined.
This inspection step takes only a few minutes and makes the Android SDK Manager cleanup process much more targeted.
Removing Unused Android SDK Platforms
Old platform packages are usually safe to remove as long as you are not actively working on a project that needs them for compilation.
In the Android SDK Manager inside Android Studio, go to the SDK Platforms tab. Any platform that is not your current compileSdk target and not needed for any active project can be unchecked and removed. Click Apply after unchecking the ones you want to remove.
From the command line:
sdkmanager –uninstall “platforms;android-31” sdkmanager –uninstall “platforms;android-32”
Replace the version numbers with whichever ones you want to remove.
Each platform package typically saves 60 to 100 MB. That might not seem like much individually, but removing five or six old platforms frees up 400 to 600 MB without any risk to your active development setup.
One important note: do not remove a platform if any of your current projects still references it in compileSdk. Check your build.gradle files first. The Android SDK Manager will let you remove it even if a project still needs it — it will just cause a build error when you try to compile.
Removing Old Build-Tools Versions
Build-tools versions accumulate more quietly than platforms. The Android SDK Manager shows them as a list, and after a year of development it is common to see four or five different versions installed.
Each build-tools version takes between 100 and 200 MB. Removing three old versions recovers 300 to 600 MB.
To identify which build-tools version your active projects actually need, open each project’s app-level build.gradle and look for:
buildToolsVersion “34.0.0”
Whatever version is specified there is the one you need. Everything else can go.
In the Android SDK Manager, go to the SDK Tools tab, click the dropdown next to Android SDK Build-Tools, and uncheck the versions you no longer need. Apply the changes.
From the command line:
sdkmanager –uninstall “build-tools;31.0.0” sdkmanager –uninstall “build-tools;32.0.0”
If you are not sure which version a project needs, it is safer to keep the two most recent ones and remove everything older than that.
Removing Unused System Images – The Biggest Space Recovery
This is where the most significant disk space recovery happens when using the Android SDK Manager for cleanup.
System images are the Android OS snapshots that your emulator boots from. Each combination of API level, variant, and ABI is a separate image. Common variants include google_apis, google_play, and default. Common ABIs include x86_64 and arm64-v8a.
If you have installed system images over time without cleaning up, you might find combinations like these all sitting on your drive:
system-images;android-30;google_apis;x86_64 system-images;android-31;google_apis;x86_64 system-images;android-32;google_play;x86_64 system-images;android-33;google_apis;x86_64 system-images;android-34;google_apis;x86_64 system-images;android-34;google_play;x86_64
That is potentially 15 to 20 GB of storage sitting there for emulators you might have created once and never used again.
To clean this up properly, first list the AVDs (emulators) you have actually created:
avdmanager list avd
This shows all your virtual devices and which system image each one uses. Keep only the system images that appear in this list. Everything else can be safely removed through the Android SDK Manager.
sdkmanager –uninstall “system-images;android-31;google_apis;x86_64”
Be careful not to remove a system image that a currently configured AVD depends on. If you do, that emulator will fail to launch until you reinstall the image. Delete unused AVDs first with:
avdmanager delete avd –name “OldEmulatorName”
Then remove the corresponding system image. This keeps your Android SDK Manager organized and your disk clean.
Cleaning Up the AVD Folder Separately
The Android SDK Manager controls SDK packages, but there is a related folder that stores your actual emulator data separately. This folder is not managed by the SDK Manager directly.
On macOS and Linux, emulator data lives at:
~/.android/avd/
On Windows:
C:\Users\YourName.android\avd\
Each AVD you create gets its own folder here, often 1 to 4 GB in size, depending on how much data has accumulated inside the virtual device from testing.
If you have deleted an AVD using avdmanager delete but its data folder still exists in .android/avd/, you can delete that folder manually to recover the space. These are safe to remove as long as you have already deleted the corresponding AVD configuration.
This cleanup step operates independently of the Android SDK Manager but pairs naturally with the system image cleanup above.
Managing SDK Storage Through the Command Line Efficiently
For developers who prefer working in the terminal, the Android SDK Manager command-line interface makes batch cleanup much faster than clicking through the Android Studio GUI.
To list everything installed with approximate sizes:
sdkmanager –list_installed
To remove multiple packages at once, chain the commands or use a simple script. On Linux or macOS:
sdkmanager –uninstall
“platforms;android-30”
“platforms;android-31”
“build-tools;30.0.3”
“system-images;android-30;google_apis;x86_64”
On Windows, run each uninstall command separately since multi-line commands work differently in Command Prompt and PowerShell.
After cleanup, run sdkmanager –list_installed again to confirm the packages are gone. Then check the actual folder size to see how much space you recovered:
du -sh ~/android-sdk/
Comparing before and after numbers gives you a clear picture of what the Android SDK Manager cleanup actually saved.
What You Should Never Remove from the Android SDK Manager
Knowing what to keep is just as important as knowing what to remove. Some packages look optional but are actually critical.
Platform-Tools should never be removed. This package contains ADB, and without ADB you cannot connect to any Android device or emulator. The Android SDK Manager shows it as a single package and it takes very little space. Keep it updated but never delete it.
The Android Emulator package itself — separate from system images — should stay installed if you use virtual devices at all. Without it, no emulator will launch regardless of how many system images you have.
The current compileSdk platform must stay. If your active project uses compileSdk 35, removing platforms;android-35 will break every build immediately.
The build-tools version referenced in your active project’s Gradle files must stay. Removing it causes the same build failure.
The Android SDK Manager does not prevent you from removing any of these — it will complete the uninstall without a warning. The consequence only appears the next time you try to build or connect to a device. Check your active project requirements carefully before removing anything.
Setting Up a Leaner SDK from the Start
If you are setting up a new development machine or reinstalling Android Studio, the best time to practice good Android SDK Manager hygiene is from the very beginning.
Instead of letting Android Studio install everything by default, go through the SDK Platforms and SDK Tools tabs during initial setup and only install what you need. For most developers starting a new project in 2026, that means:
platforms;android-35 for the current compileSdk target. build-tools;35.0.0 or whatever your Gradle configuration specifies. platform-tools for ADB. emulator if you plan to use virtual devices. One system image matching the Android version you want to test on.
Starting lean means the Android SDK Manager never accumulates years of unused packages in the first place. It is significantly easier to maintain a clean SDK than to clean up a bloated one.
Final Conclusion
The Android SDK Manager is a powerful tool that most developers underestimate. It is not just for installing packages — it is also your primary tool for keeping your development machine lean and organized. In 2026, with storage prices what they are and SSDs filling up faster than ever, taking an hour to audit your SDK installation is genuinely worthwhile.
The biggest wins come from removing old system images you no longer test on, clearing out platform packages that no active project references, and deleting redundant build-tools versions. Together, these steps can recover 10 to 25 GB depending on how long the SDK has been accumulating unused packages.
The Android SDK Manager makes all of this possible through either the graphical interface in Android Studio or the sdkmanager command-line tool. Both work well. The important thing is to actually do the cleanup rather than ignoring it until your drive is full.
For a full reference on every package available through the Android SDK Manager, the official sdkmanager documentation and the Android Studio release notes are the best places to stay current with what is available and what has changed.
