How to clear the Gradle cache on Mac
GRUJ clears the Gradle cache (~/.gradle/caches) on Mac — downloaded dependencies and build artifacts — plus unused AVDs and per-project build folders. Gradle redownloads what it needs on your next build. It never touches your code, your projects or the Android SDK. Typical haul: 10-100 GB.
brew install --cask fan2dev/tap/gruj 3 months free · no card · direct download (outside the App Store)
Why is Android Studio using 100 GB?
It is never one folder. ~/.gradle/caches stacks every dependency version you ever built against. ~/.android/avd holds emulator disk images at 8-15 GB each. ~/Library/Android/sdk piles up old build-tools, system images and emulator releases. Then every project carries its own build/, app/build/ and .gradle/. On a real Mac a single Pixel AVD already eats 11 GB, and an SDK folder routinely hits 16 GB. Android Studio cleans almost none of it for you.
Scan
Run gruj scan (or open the menu-bar app). GRUJ finds ~/.gradle/caches, the modules-2 dependency cache, the build-cache-1 task-output cache, the Kotlin daemon cache, unused AVDs in ~/.android/avd and stray per-project build/ folders — with the exact size of each.
Choose
Pick what to wipe. Keep the AVD you actually test on, drop the three you forgot about. Clear the dependency cache but leave the SDK. Every item shows its size and a risk level so you decide, not the tool.
Confirm
Run gruj clean and confirm. GRUJ deletes only the regenerable paths on its allowlist. Your next Gradle build redownloads dependencies once (slower that one time), then you are back to fast — with the space reclaimed.
It knows where Gradle hides
~/.gradle/caches/modules-2 (dependencies), build-cache-1 (task outputs), the Kotlin daemon cache, the Gradle wrapper dists, plus per-project build/ and .gradle/ folders. One scan, all of it.
Unused AVDs, gone
Each Android emulator image in ~/.android/avd runs 8-15 GB — on this Mac a single Pixel AVD is 11 GB. GRUJ lists them with sizes so you keep the one you use and reclaim the rest, no fumbling through Device Manager.
It will NOT delete your SDK
GRUJ never wipes ~/Library/Android/sdk wholesale — that holds your build-tools, platforms and the emulator binary, often 15+ GB. It only targets regenerable caches and the AVDs you flag. This is the line generic cleaners cross.
Size before you delete
Generic cleaners show a vague 'junk' total. GRUJ shows the real GB per cache, per AVD, per project build folder — before anything is touched. You see the trade, then decide.
Skips what is in use
If a build is running or the cache is locked, GRUJ skips that target instead of corrupting it. Anti-symlink guards keep it from following a link out of the allowlist.
Beyond Android
Same scan also sweeps Xcode DerivedData, Flutter .pub-cache, node_modules, Docker and more — so you are not running a different command for every stack.
By hand vs. GRUJ
| GRUJ | By hand / generic | |
|---|---|---|
| Clear dependency cache | gruj clean after scan + confirm | rm -rf ~/.gradle/caches/modules-2 |
| See size before deleting | shown per item in the scan | compute by hand with du -sh ~/.gradle/caches |
| Find & delete unused AVDs | listed with sizes, you pick | hunt through ~/.android/avd or Device Manager |
| Per-project build/ folders | found across all your projects in one scan | find and rm each one manually |
| Risk of deleting too much | low — SDK is never on the allowlist | high — one wrong path nukes ~/Library/Android/sdk |
| Gradle + Flutter + Docker at once | yes, one scan | no — a separate command per tool |
FAQ
Is it safe to delete the Gradle cache?
Yes. ~/.gradle/caches holds dependencies and build artifacts that Gradle redownloads on the next build. Deleting it does not affect your source code; it only makes the next compile slower once while it re-fetches.
Where is the Gradle cache on Mac?
It lives at ~/.gradle/caches in your home folder. The biggest part is ~/.gradle/caches/modules-2 (downloaded dependencies); ~/.gradle/caches/build-cache-1 holds cached task outputs.
What is the best way to clear the Gradle cache on Mac?
For a one-off, rm -rf ~/.gradle/caches/modules-2 clears the dependency cache fine. For the full job — seeing each size first, also clearing build-cache-1, unused AVDs and per-project build folders, without risking your SDK — run gruj scan then gruj clean.
Why is Android Studio using 100 GB?
It is spread across the Gradle cache (~/.gradle/caches), AVD emulator images (~/.android/avd, 8-15 GB each), the Android SDK (~/Library/Android/sdk, often 15+ GB), and a build/ folder inside every project. Almost none of it is cleaned automatically.
Can I delete the .gradle folder?
You can safely delete ~/.gradle/caches and ~/.gradle/daemon. Leave ~/.gradle/gradle.properties and init scripts if you have custom config — those are not regenerated. GRUJ targets only the regenerable caches inside .gradle, not your settings.
How do I delete Android emulators to free space?
Each AVD sits in ~/.android/avd as a folder of disk images, often 8-15 GB. Delete the .avd folder and its .ini for emulators you no longer test on. GRUJ lists every AVD with its real size so you keep the one you use and reclaim the rest.
Will GRUJ delete my Android SDK?
No. GRUJ never wipes ~/Library/Android/sdk — that holds your build-tools, platforms and the emulator. It only deletes regenerable caches (~/.gradle/caches), per-project build folders and the unused AVDs you select.
Does clearing the cache break my project?
No. Your code, Gradle config and the SDK stay put. The only effect is that your next build redownloads dependencies once, so it takes longer that single time, then runs at full speed again.
Reclaim that 100 GB Android Studio is hoarding
Scan the Gradle cache, AVDs and build folders in one shot. See the real GB, wipe only what regenerates, never touch your SDK or your code. Free while GRUJ is in pre-launch.
Download free