Android Studio eating 50–100 GB on your Mac? Here's what to clear

Open Storage settings after a few months of Android work and the numbers don't add up. Android Studio is nowhere on the list, but tens of gigabytes are gone. If Android Studio disk space on your Mac has quietly climbed toward 50–100 GB, almost none of it is the IDE. It's generated caches, emulator disk images, and stacked-up SDK downloads that never clean themselves. Here's exactly where the space goes, and what's safe to clear.

Where Android Studio's disk space actually goes on your Mac

None of the big folders are your project source. They're caches and downloaded artifacts Android Studio creates as you build, sync, and run emulators, and most are never pruned. Here's the breakdown with real paths:

The two silent killers are AVD emulators and SDK system images. Every virtual device you create carries its own multi-GB disk, and every API level you've ever tested against pulls down its own system image, and neither gets removed when you stop using it. A handful of old emulators plus a few obsolete API levels is how a machine ends up hiding well over 50 GB it isn't using.

Find the hogs first

Before deleting anything, measure. This lists the three main sinks so you clear the real offenders instead of guessing:

du -sh ~/.gradle ~/.android ~/Library/Android/*

To break the emulators and system images down individually:

du -sh ~/.android/avd/*
du -sh ~/Library/Android/sdk/system-images/*

What's safe to clear

Gradle caches: ~/.gradle/caches

This is a pure cache: downloaded dependencies, the build cache, and wrapper distributions. Delete it and Gradle re-downloads and rebuilds on the next sync:

rm -rf ~/.gradle/caches

The only cost is that the first build after is slower. It has to re-fetch dependencies over the network and repopulate. It's the Android equivalent of deleting node_modules: generated, not source, fully reproducible. (Same logic, JavaScript side: is it safe to delete node_modules.) For a lighter touch that only clears one project's build output, run ./gradlew clean in that project instead.

Unused AVD emulators

Each virtual device is a separate multi-GB disk image, and they linger long after you've moved on. In Android Studio, open Device Manager (Tools → Device Manager), then use the dropdown next to any device you don't use and choose Delete. That reclaims its disk image in ~/.android/avd. You can also delete the matching *.avd folder directly:

rm -rf ~/.android/avd/Pixel_6_API_31.avd

Recreating an emulator later takes a minute but costs nothing you can't get back.

Old SDK system images and platforms

System images are the big ones. Each API level and variant (Google APIs, Play Store, ARM vs x86) is its own multi-GB download. Open SDK Manager (Tools → SDK Manager), and on the SDK Platforms tab check "Show Package Details," then untick the API levels and system images you no longer target. On the SDK Tools tab, remove old build-tools versions you don't build against. Apply, and the SDK Manager deletes them cleanly under ~/Library/Android/sdk. Keep the one or two API levels you actually ship against; drop the rest.

Build output and Android Studio caches

Per-project build/ and .gradle/ folders regenerate on the next build, so they're safe to remove for projects you've archived. Android Studio's own caches and logs live under ~/Library/Application Support/Google/AndroidStudio* and ~/Library/Logs/Google/AndroidStudio*; the safe way to clear the IDE cache is File → Invalidate Caches rather than deleting by hand.

Why it hides as "System Data"

The frustrating part is that all of this sits in your home folder and ~/Library, so macOS Storage settings can't itemize it. It gets swept into System Data, the catch-all bucket Apple won't let you open, which is why deleting apps and emptying the Trash never seems to move the needle. Android's caches are one of the biggest contributors to that mystery number on a developer's Mac, right alongside Xcode. For the full map of what's actually in that bucket, see where hidden storage goes on a Mac, and if you also build for iOS, Xcode's own 20–50 GB of caches and simulators stack on top of this.

Do it without hunting through Terminal

Running du, reading version numbers off system-image folders, and hand-deleting emulators works, but it's tedious, and one careless rm -rf in the wrong directory is unforgiving. Plumby finds your Gradle caches, every AVD disk image, and stale SDK system images, shows each with its exact path and measured size, and clears only what you approve. It acts only on your command and never touches your project source, just the regenerable build junk.