Android tooling spreads itself across four hidden directories, and none of them have a size limit. The IDE is the small part at around 2GB. The damage is done by emulator images, Gradle caches, the SDK and the build outputs of every project you have opened.
Measure all four
du -sh ~/.android/avd
du -sh ~/.gradle
du -sh ~/Library/Android/sdk
du -sh ~/Library/Android/sdk/system-imagesSix emulators at 15GB each is 90GB, and that is a completely ordinary result for someone who has been building Android apps for a year or two.
Back up your signing keys first
~/.android alongside the caches. Caches are replaceable, your app signing identity is not. Copy any .jks or .keystore file somewhere safe, and confirm you can still sign a build before and after any cleanup.
Emulator images: the biggest single win
Every Android Virtual Device keeps its own disk image in ~/.android/avd, sized between 6GB and 20GB. These are the files that make a clean looking machine run out of space.
du -sh ~/.android/avd/*.avd | sort -hrDelete them the supported way, through Android Studio's Device Manager, so the related configuration files go too. A device you have not booted in the last month is a candidate, and you can recreate it in a few minutes from the same API level if you need it again.
Gradle caches
Gradle downloads every dependency for every project and keeps each version forever, along with transform outputs generated from them.
du -sh ~/.gradle/caches
./gradlew --stop
rm -rf ~/.gradle/caches/transforms-*Deleting the transform caches is safe and they are regenerated on the next build. Deleting ~/.gradle/caches/modules-2 is also safe but costs you a full re-download of every dependency, so do it when you have a good connection. Stop any running Gradle daemon first, otherwise it holds open file handles and rewrites what you delete.
SDK packages and old build tools
The SDK directory keeps every platform, build tools version and system image you have ever installed, including the ones no current project targets.
du -sh ~/Library/Android/sdk/* | sort -hrOpen the SDK Manager inside Android Studio and remove platform versions and system images you no longer build against. It performs the removal cleanly and updates the package indexes, which manual deletion does not.
Project build folders
Every module keeps its own output in build directories. On a large project these reach several gigabytes each and survive every branch switch.
find ~/AndroidStudioProjects -name build -type d -prune -exec du -sh {} + | sort -hrCleaning them is what ./gradlew clean does, one project at a time. Doing it across all of them at once trades disk space for a slower first build, which is usually the right trade on a laptop.
macoptimize scans the Android caches along with Xcode and Node output. Emulator images show up in the Analyze treemap as single large blocks, which makes it obvious that a 15GB file inside a dot folder in your home directory is what is filling the drive. The Clean tab then removes the selected ones and logs the result.
The five folders, with real numbers
| Path | Holds | Typical size |
|---|---|---|
| ~/.android/avd | Emulator disk images and snapshots | 6GB to 20GB per device |
| ~/.gradle/caches | Downloaded dependencies and build cache | 5GB to 30GB |
| ~/Library/Android/sdk | Platforms, build tools, system images | 10GB to 60GB |
| ~/Library/Android/sdk/emulator | Emulator binaries and skins | 2GB to 6GB |
| Project build folders | Compiled output per module | 0.5GB to 5GB per app |
The SDK folder is the one people forget to measure, partly because it lives in Library rather than in the home folder root. It is also the only one of the five that contains something genuinely hard to re-download, which the next section covers.
What is safe to delete, and what is not
- Safe to delete:
~/.gradle/caches, projectbuildandapp/buildfolders, emulator snapshots, old system images, and AVDs you no longer boot. - Safe to delete after checking: old platform versions in the SDK, like API 29 when you target 34.
- Never delete:
~/.android/debug.keystore, any.jksor.keystorefile, and the SDKplatform-toolsfolder. Losing a signing key means you cannot publish an update to an app that already exists on the Play Store. Back these up before any cleanup, and store a copy somewhere outside the machine.
Check for a signing key first. Run find ~ -name "*.jks" -o -name "*.keystore" 2>/dev/null and confirm every result is either backed up or reproducible. It is a two minute check that prevents an unrecoverable mistake.
Reclaiming the emulator, step by step
avdmanager list avd
emulator -list-avds
du -sh ~/.android/avd/*The size list is the useful part. Each AVD folder holds a userdata image that grows with every session, plus snapshots. Two moves return most of it:
- Wipe a device you still need with
emulator -avd Pixel_7_API_34 -wipe-data, which resets it to a clean state without losing the device definition. - Delete the ones you never boot from Android Studio's Device Manager, which removes the AVD folder as well.
Snapshots are the quiet part of this. A device configured to save a snapshot on close stores the entire memory state, which can be several gigabytes per device, and it is the reason an AVD listed as 6GB can occupy 14GB on disk.
Gradle: what the cache really contains
~/.gradle/caches holds downloaded dependency jars, transformed artifacts, and the build cache from every project you have ever synced. Two subfolders dominate:
caches/modules-2is the dependency store. Deleting it means re-downloading everything at the next sync.caches/build-cache-1is task output that speeds up incremental builds. Deleting it is always safe and never breaks a build.
There is also a per project .gradle folder inside each project, which holds configuration cache and file hashes. Deleting that forces a re-configuration on the next build, which takes a minute and fixes a surprising number of strange build errors.
After the wipe: rebuilding the setup
If you deleted the SDK or the AVDs, the recovery path is short. Open Android Studio, let the SDK Manager re-download the platforms and build tools you target, then create the devices again in Device Manager. Budget 20 to 40 minutes depending on your connection, and expect the first Gradle sync in each project to be slow. Keep a note of the API levels your projects target so you re-download those and not the whole catalogue.
FAQ
Can I delete an AVD and recreate it later?
Yes. The AVD is a configuration plus a disk image, both of which Android Studio recreates. Note the device profile, the API level and whether it was arm64, recreate it in Device Manager, and the new one behaves the same. You lose anything installed inside the emulator, which usually does not matter.
Is it safe to delete the whole ~/.gradle folder?
It is safe in the sense that nothing breaks permanently, but it is the most expensive single delete in Android development. The next sync re-downloads every dependency for every project, which on a slow connection can take an hour. Delete caches/build-cache-1 first and stop there if that was enough.
How much space can Android tooling take in total?
A working setup with three or four emulators, a full SDK and a few years of Gradle caches commonly sits between 40GB and 100GB. Emulators and system images are usually the largest part, and they are also the part people forget to measure because the folders are hidden.
Do I need to back up my signing keys before cleaning?
Yes, and it takes two minutes. Debug keystores regenerate automatically, but a release keystore cannot. Without it you cannot publish an update to an app already on the Play Store, and no support channel can recover it for you.
Will deleting build folders break Android Studio?
No. Build folders are compiled output and Android Studio regenerates them on the next build, though the first one afterwards is a full build rather than an incremental one. It is also a well known fix for resource merging errors and stale generated classes.