Android Studio Is Using 50GB+: Clean AVDs, SDKs & System Images on Mac

If you develop for Android on a Mac, you have almost certainly opened Disk Utility one day and felt genuine alarm. Android Studio disk space usage on Mac can quietly balloon past 50 GB — sometimes well past 100 GB — without you doing anything obviously wrong. The culprit is rarely one thing; it is a combination of emulator snapshots, stacked SDK system images, old NDK toolchains, and a build cache that never clears itself. This guide breaks down each offender, tells you what is genuinely safe to remove, and shows you the Terminal commands to do it cleanly.

Why Android Studio Takes Up So Much Space

Android Studio stores data in several places across your home directory. The biggest are:

• AVD files — ~/.android/avd/
• SDK components — typically ~/Library/Android/sdk/
• Gradle build cache — ~/.gradle/caches/
• IDE caches and logs — ~/Library/Caches/Google/AndroidStudio*/ and ~/Library/Logs/Google/AndroidStudio*/
• Android Studio system directory — ~/Library/Application Support/Google/AndroidStudio*/

None of these locations are surfaced by macOS's built-in "Manage Storage" view, which is why so many developers are blindsided.

The Biggest Offenders, Ranked

1. AVD Snapshots (Often 5–20 GB Each)

Every Android Virtual Device you create lives at ~/.android/avd/<device-name>.avd/. The raw disk image (userdata-qemu.img) is sizeable on its own, but the real space drain is snapshots. When "Save quick-boot state" is enabled (the default), Android Studio writes a full memory and storage snapshot every time you close an emulator. These accumulate in a snapshots/ subdirectory and can easily exceed the base image in size.

To see what you are dealing with:

du -sh ~/.android/avd/*

Safe to delete: Individual snapshot folders inside ~/.android/avd/<name>.avd/snapshots/. The emulator will cold-boot next time, which takes a little longer, but nothing is permanently lost.

Also safe: Entire .avd directories for emulators you no longer use. The matching .ini file in ~/.android/avd/ should be removed at the same time.

# List all AVDs
emulator -list-avds

# Delete a specific AVD (the clean way)
avdmanager delete avd -n Pixel_7_API_34

Using avdmanager is safer than deleting the folder by hand because it removes both the directory and the ini reference atomically.

2. SDK System Images (2–8 GB Per Image)

Each combination of API level, ABI (x86_64, arm64-v8a), and image type (Google APIs, Play Store, AOSP) is a separate download. You only need the images that match emulators you actively run. Everything else is dead weight.

System images live at:

~/Library/Android/sdk/system-images/

Check sizes:

du -sh ~/Library/Android/sdk/system-images/*/*

Safe to delete: Any system image folder for an API level you no longer target, or for an ABI you do not use (most Apple Silicon Macs can delete x86_64 images if you have the arm64-v8a equivalents). Re-downloading takes a few minutes via the SDK Manager.

Not safe to delete without thinking: The image backing an AVD you still use. Check which image each AVD references in its config.ini before deleting.

3. NDK Installations (1–4 GB per Version)

If your project uses native C/C++ code, you will have at least one NDK installed. If you have been developing for a while, you probably have several versions stacked up:

ls ~/Library/Android/sdk/ndk/

Safe to delete: Any NDK version not pinned by your project's android.ndkVersion property. Keep only the version(s) your active projects specify.

4. Gradle Build Cache

Gradle's cache is designed to speed up incremental builds, but it has no built-in expiry. Over years of development it can grow very large.

du -sh ~/.gradle/caches/

Safe to delete: The entire ~/.gradle/caches/ directory. Gradle will rebuild the cache from your local Maven repository and remote dependencies on the next build. Expect a slower first build after clearing it.

rm -rf ~/.gradle/caches/

5. IDE Caches and Logs

Android Studio (which is IntelliJ-based) keeps per-version caches and logs. When you upgrade to a new major version, the old directories are left behind.

# Caches
ls ~/Library/Caches/Google/

# Logs
ls ~/Library/Logs/Google/

# Application support (plugins, indexes)
ls ~/Library/Application\ Support/Google/

Safe to delete: Directories for versions of Android Studio you no longer have installed. The current version's cache can also be deleted; Android Studio will re-index on next launch (slow, but harmless).

rm -rf ~/Library/Caches/Google/AndroidStudio2022.3/
rm -rf ~/Library/Logs/Google/AndroidStudio2022.3/

How to Find the Biggest Directories Fast

Before deleting anything, it helps to see the full picture. A one-liner that shows the ten largest directories inside your home folder:

du -d 3 ~ 2>/dev/null | sort -rn | head -20

If you want a visual rather than a terminal dump, Crumb's whole-Mac audit does exactly this — it maps your entire disk by folder size and surfaces the largest items across all directories, including the hidden ~/.android and ~/Library/Android trees that macOS Storage normally buries. It is a fast way to confirm which SDK or AVD directory is actually the biggest before you start deleting.

What Is Safe to Delete vs. What to Keep

A Systematic Cleaning Run

1. Open a terminal and run du -sh ~/.android/avd/* ~/Library/Android/sdk/system-images/*/* ~/.gradle/caches/ to get a baseline.
2. In Android Studio, open Device Manager and delete any AVDs you no longer use via the UI (safest method).
3. Open SDK Manager (Settings → Languages & Frameworks → Android SDK) and uncheck system images for API levels you do not target, then click Apply.
4. In SDK Manager, do the same for NDK versions you do not need.
5. Clear the Gradle cache from terminal: rm -rf ~/.gradle/caches/
6. Remove old IDE caches for versions no longer installed: rm -rf ~/Library/Caches/Google/AndroidStudio<old-version>/
7. Run the du command again to confirm how much you recovered.

If you want a second pass to catch anything the SDK Manager missed — stale build outputs in project build/ directories, leftover emulator disk images from manually-deleted AVDs, or orphaned Gradle wrapper downloads — download Crumb and run the whole-Mac audit. It will show those directories grouped by size so you can decide what to keep without guessing.

Preventing the Accumulation

• Turn off quick-boot snapshots for emulators you use infrequently: AVD Manager → Edit → Show Advanced Settings → set "Cold boot" instead of "Quick boot."
• Limit to one system image per API level you actively test on. Prefer arm64-v8a on Apple Silicon.
• Run ./gradlew cleanBuildCache or delete ~/.gradle/caches/ a few times a year.
• Upgrade Android Studio in place rather than installing side-by-side versions, and remove old version directories promptly after upgrading.

Conclusion

Android Studio disk space on Mac is a solvable problem once you know where the weight lives. AVD snapshots and stacked system images are almost always the biggest culprits, and both are safely re-creatable or re-downloadable. The build cache is safe to nuke entirely. A one-time audit with du or a visual tool like Crumb will show you the scale before you commit to any deletions — and the table above tells you which items you can remove confidently versus which ones will break your workflow if they disappear.