Where the gigabytes actually live
Android's disk appetite splits across four territories, and knowing the paths matters because the IDE only manages one of them. The SDK lives under %LOCALAPPDATA%\Android\Sdk, the emulator's virtual devices under %USERPROFILE%\.android\avd, and Gradle under %USERPROFILE%\.gradle — each with its own cleanup rules and its own way of biting you if you delete blindly.
The worst offenders are the SDK system images: every Android version × CPU architecture combination you ever accepted, one to two GB apiece, kept forever. Emulator AVDs come second — a single virtual device with snapshots and its qcow2 disk can pass 10 GB. Gradle caches accumulate every dependency every project ever resolved, and every per-project build/ folder piles up intermediates you already forgot existed.
- %LOCALAPPDATA%\Android\Sdk\system-images — every Android version and ABI combo you ever downloaded, 1–2 GB each
- %USERPROFILE%\.android\avd — emulator images; one AVD with snapshots and qcow2 disks easily passes 10 GB
- %USERPROFILE%\.gradle\caches — every dependency every project resolved, safely rebuildable and often 20 GB+
- %USERPROFILE%\.gradle\wrapper\dists — every Gradle version any project ever requested, roughly 150 MB each
- build/ and .gradle/ inside each project — intermediates and per-project caches you can delete any time
- %LOCALAPPDATA%\Google\AndroidStudio* — the IDE's own indexes, logs and caches, reborn after every upgrade
What is safe to delete — and what never is
Delete through the manager screens wherever one exists. In SDK Manager, uninstall system images and old build-tools for Android versions below your minSdk; it updates the metadata and keeps the SDK consistent. In Device Manager, delete AVDs you no longer use, and for a misbehaving one prefer Wipe Data in its dropdown — a factory reset instead of keeping a 10 GB fossil.
Gradle caches can be wiped wholesale — the next build re-downloads what it needs, and you pay with time and bandwidth, not breakage. The same goes for per-project build folders, which is why archiving a project deserves a build/ purge first. What you never blanket-delete is %USERPROFILE%\.android itself: it holds your debug keystore and adb keys, and losing the debug keystore means reinstalling every debug build on every device you own.
Keeping it lean going forward
Bake three habits into the routine. When minSdk moves up, spend five minutes in SDK Manager dropping the versions below it. Keep one current emulator image per form factor instead of five, and prefer Wipe Data over snapshots when you just need a fresh device. If C: is under pressure, move the SDK via Settings → Languages & Frameworks → Android SDK and point GRADLE_USER_HOME at another drive.
For the recurring leftovers — Gradle caches, IDE caches and logs, project build folders — a cleanup pass twice a year keeps the total in check. A tool that knows the developer folders, like Kleaner PRO's dev-caches category, clears Gradle and IDE leftovers in one pass while leaving keystores alone; whichever way you do it, close Studio first so nothing is locked mid-delete.
Questions and Answers
Is it safe to delete the Gradle cache folder?
Yes — close Studio first, then delete %USERPROFILE%\.gradle\caches. The next build re-downloads whatever it needs; the cost is time, not breakage.
How do I free up space from Android emulators?
In Android Studio, open Device Manager, delete AVDs you no longer use, and run Wipe Data on the ones you keep — a single forgotten image can hold 10 GB.
Know what is included before you buy.
The one-time 30-minute trial covers core tools. PRO-labelled features stay locked until a paid license is activated.
Read next
Write to us: [email protected]