Android Studio & Gradle Caches Are Huge: Clean Them on Mac (2026)

If you develop Android apps on a Mac, your disk usage can quietly balloon into tens of gigabytes — not from your source code, but from the toolchain surrounding it. Gradle cache taking up space on Mac is one of the most common complaints from cross-platform developers who suddenly find themselves with a full disk and no obvious culprit. This guide walks through exactly where that space goes, what is safe to delete, and how to reclaim it without breaking your builds.

Where Android Development Eats Your Disk

Before deleting anything, it helps to understand the four main categories of disk hogs on a Mac running Android Studio:

• Gradle build caches and wrapper distributions — the biggest offender for most developers
• Android Studio application caches — IDE indexes, logs, and local state
• Android Virtual Device (AVD) emulator images — each system image is typically 2–8 GB
• Old Android SDK platforms and build tools — versions you no longer target

Gradle Cache Taking Up Space on Mac: What Lives in ~/.gradle

Gradle stores almost everything under ~/.gradle. On a project that has been active for a year or two, this folder routinely reaches 10–30 GB. The subdirectories that matter most are:

• ~/.gradle/caches/ — compiled build outputs, resolved dependency JARs, Kotlin build reports, and incremental build data. This is the largest sub-directory and the safest to delete.
• ~/.gradle/wrapper/dists/ — downloaded Gradle distribution ZIPs, one per version your projects have ever used. Each unzipped distribution is 80–200 MB.
• ~/.gradle/daemon/ — logs from long-running Gradle daemon processes. Pure logs; always safe to delete.

Checking the Size First

du -sh ~/.gradle/caches ~/.gradle/wrapper ~/.gradle/daemon

Deleting Gradle Caches Safely

The caches directory rebuilds automatically on the next build, fetching dependencies from the network and re-resolving your project graph. The first build after deletion will be slower than normal; subsequent builds restore to full speed.

1. Quit Android Studio and stop any running Gradle daemons:

   ./gradlew --stop

2. Delete the caches directory:

   rm -rf ~/.gradle/caches

3. Optionally remove old wrapper distributions you no longer need (keep the version your current projects use):

   ls ~/.gradle/wrapper/dists/
   rm -rf ~/.gradle/wrapper/dists/gradle-7.4.2-bin

4. Delete daemon logs:

   rm -rf ~/.gradle/daemon

Important: Do not delete ~/.gradle/gradle.properties or any files directly inside ~/.gradle/ itself — those contain your personal Gradle configuration and any credentials you have stored for private artifact repositories.

Clean Android Studio Cache on Mac

Android Studio keeps its own system caches — IDE indexes that speed up code completion, find-usages, and inspections. These live outside the project directory and outside ~/.gradle.

Where Android Studio Caches Live

• System caches: ~/Library/Caches/Google/AndroidStudio<version>/
• Local state (logs, recent projects list): ~/Library/Application Support/Google/AndroidStudio<version>/
• Preferences: ~/Library/Preferences/Google/AndroidStudio<version>/

Using the Built-in Invalidate Caches Command

The cleanest way to reset IDE caches without touching your settings is to use Android Studio's built-in command:

1. Open Android Studio.
2. Go to File > Invalidate Caches…
3. Check Clear file system cache and Local History and Clear VCS Log caches and indexes.
4. Click Invalidate and Restart.

Android Studio will rebuild its indexes on the next startup — this takes a few minutes for large projects but restores everything automatically.

Deleting the Cache Folder Manually

If you want to reclaim the raw disk space rather than just invalidate the index:

rm -rf ~/Library/Caches/Google/AndroidStudio*

This is safe. The IDE recreates this folder and rebuilds its indexes on next launch.

Delete .gradle Caches Folder vs. Project-Level .gradle

Individual projects may also contain a .gradle/ folder at the project root. This holds project-level Gradle configuration cache data, distinct from the global ~/.gradle/caches. Both are safe to delete; both rebuild on the next Gradle invocation.

# Inside your project directory:
rm -rf .gradle/

Android SDK System Images and Disk Space

AVD emulator system images are the single largest per-item entries you are likely to find. Each image includes a full Android OS and often a Google Play Store snapshot. They do not rebuild automatically — if you delete a system image, you need to re-download it from the SDK Manager before that emulator configuration can be used again.

Finding Your SDK Location

By default the Android SDK installs to:

~/Library/Android/sdk/

Confirm yours in Android Studio under Settings > Appearance & Behavior > System Settings > Android SDK.

What You Can Safely Remove

Removing Old SDK Platforms via SDK Manager (Recommended)

Rather than deleting SDK folders by hand, use Android Studio's SDK Manager so the IDE stays in sync:

1. Open Settings > Appearance & Behavior > System Settings > Android SDK.
2. On the SDK Platforms tab, uncheck any API levels you are not actively building for or testing against.
3. On the SDK Tools tab, check Show Package Details and uncheck old build-tools versions.
4. Click Apply and confirm the uninstall.

Deleting AVD Emulator Images

AVD data lives in ~/.android/avd/. To remove an emulator you no longer use:

1. Open the Device Manager in Android Studio.
2. Click the three-dot menu next to the AVD and choose Delete.
3. Confirm. This removes both the configuration file and the disk image, which can be several gigabytes.

Cleaning Everything at Once with Crumb

If you also work with Xcode and want to clear all developer caches — Gradle, Android Studio, Xcode derived data, and iOS simulator runtimes — in a single pass, Crumb handles this under its Developer cleanup category. It surfaces Gradle and Android caches alongside Xcode entries so you can review and remove them together without hunting through multiple Library folders. That is particularly useful when you are a cross-platform developer and both toolchains accumulate independently over time.

You can download Crumb and use one cleanup for free to see how much space the combined developer cache sweep recovers before deciding whether the full version is worth it for your workflow.

Summary: Safest Deletion Order

1. Stop Gradle daemons (./gradlew --stop), then delete ~/.gradle/caches/ and ~/.gradle/daemon/ — largest payoff, zero risk.
2. Delete ~/Library/Caches/Google/AndroidStudio*/ — IDE rebuilds indexes on next open.
3. Remove old SDK platforms and build-tools via SDK Manager — permanent removal, re-download if needed later.
4. Delete unused AVDs via Device Manager — permanent, includes the large disk image file.
5. Remove old Gradle wrapper distributions under ~/.gradle/wrapper/dists/ for versions no project needs.

After one round of this cleanup, scheduling a quick check every few months — especially after major SDK or Gradle version upgrades — keeps the accumulation from reaching the point where it surprises you with a full-disk error mid-build.