When Android Studio is taking too much space on a Mac, the app is rarely the problem. The space goes to what it downloads and builds around it: the Android SDK with its platforms, build tools and NDK versions, and emulator system images.
Add the virtual devices you've created, Gradle's caches, and a folder of caches for every version of Android Studio you've run, and the total can dwarf the app.
Each of those has its own place to clean it up. Uninstall SDK packages and system images in the SDK Manager, delete virtual devices in the Device Manager, and let Gradle trim its own caches or move them to the Trash in Finder.
Old Android Studio versions' folders go through a dialog Android Studio shows when you first run a new major version.
A few things should stay: the hidden ~/ folder as a whole, your Gradle settings file, and release builds you may need to read crash reports. The sections below go through every folder, what removing it costs, and how to keep it from growing back.
Android Studio taking too much space on a Mac: where it goes
Android Studio spreads its data over several folders, some of them hidden. Knowing which is which is most of the work, because each one is cleaned up a different way.
The folders, at a glance
| Location | What it holds | Where to clean it up |
|---|---|---|
~/Library/Android/sdk | The Android SDK: platforms, build tools, emulator, NDK, system images | SDK Manager |
~/.android/avd | Your virtual devices, with their data and snapshots | Device Manager |
~/.gradle | Gradle's caches, Gradle versions, downloaded JDKs, your Gradle settings | Gradle, or Finder for caches |
~/Library/Caches/Google/AndroidStudio… | Indexes, caches and local history, one folder per version | Android Studio, or Finder with it quit |
~/Library/Logs/Google/AndroidStudio… | Android Studio's logs, one folder per version | Finder |
~/Library/Application Support/Google/AndroidStudio… | Settings and plugins, one folder per version | Android Studio's leftover-folders dialog |
A build folder in each project and module | Compiled code, APKs, app bundles, test reports | Finder, project by project |
The version folders have names such as AndroidStudio2025.1. Android's troubleshooting documentation lists the configuration, plugins, system and logs folders above as Android Studio's own locations on a Mac.
Which Storage settings category counts them?
macOS doesn't know these folders. In System Settings › General › Storage, what's in your Library folder and hidden folders such as ~/ usually lands in System Data, which Apple describes as files that don't fall into the other categories. Build folders inside your projects count wherever the projects live, often Documents.
The route is the same in macOS 27 Golden Gate and macOS 26 Tahoe. Before macOS Ventura, it was Apple menu › About This Mac › Storage.
How do you see each folder's size?
Folders whose names start with a period are hidden in Finder, and the Library folder is out of sight too. To check them:
- In Finder, choose Go › Go to Folder.
- Type a location from the table, such as
~/, and press Return.Library/ Android/ sdk - Select a folder inside it and choose File › Get Info, or press Command-I, to see its size.
For a single virtual device, Android Studio has a shortcut: in the Device Manager, open the device's menu and choose Show on Disk. The SDK Manager shows the SDK's folder at the top of its window, as Android SDK Location.
The Android SDK: platforms, build tools and the NDK
The SDK is where most of the space usually is. Emulator system images are part of it, alongside platforms, build tools and NDK versions, and old versions of each stay until you uninstall them.
What's in the SDK folder?
| Folder in the SDK | What it is | How many accumulate |
|---|---|---|
platforms | One Android platform per API level you compile against | One per version you've targeted |
build-tools | Tools that package your app | One per version a project asked for |
ndk | The Native Development Kit, for C and C++ code | One per version, side by side |
system-images | Copies of Android for the emulator | One per version, device type and processor |
emulator, platform-tools | The emulator and tools such as adb | Usually one current copy |
cmake, sources | Build tools for native code; platform source code | One per version you installed |
The emulator and platform tools update in place. The others are installed side by side, so every Android version you've ever built for or tested on can still be there.
How do you uninstall SDK packages you don't need?
- In Android Studio, choose Tools › SDK Manager.
- Click SDK Platforms or SDK Tools, and select Show Package Details to see every version separately.
- Clear the checkbox next to each package you no longer need. Android Studio marks pending removals with a red X.
- Click Apply or OK, and confirm.
Android's documentation describes the same steps: clearing a checkbox uninstalls that package. The catalog's entry for the SDK adds what it costs: a project that needs an uninstalled package can't build until you install it again with the SDK Manager.
Which SDK packages are worth keeping?
Android's documentation calls a few packages required: the build tools, the platform tools, the command-line tools and at least one SDK platform to compile against. Beyond those, keep what your current projects use.
| Package | Keep | Usually safe to remove |
|---|---|---|
| SDK platforms | The one each project compiles against, usually the newest | Old API levels no project targets |
| Build tools | The versions your projects name | Older versions nothing asks for |
| NDK | Versions your native projects pin | Versions no project uses |
| System images | One per device type and API level you test | Images of versions you've stopped testing |
| Sources for Android | The newest, if you read platform code | Older versions |
If you remove something a project still needs, nothing is lost for good. The project can't build until you install the package again in the SDK Manager.
System images multiply quietly. Android's documentation notes that apps using Google Play services need a Google APIs or a Google Play image, so one Android version can end up with several variants. Keep the one your app needs and the processor type your Mac runs.
How do you know which versions your projects use?
Each module's build file, build.gradle or build.gradle.kts, names three versions. compileSdk is the platform it builds against, targetSdk the version it's tested for, and minSdk the oldest it supports. A project's ndkVersion, when it has one, pins its NDK.
Open the build files of the projects you still work on, note those numbers, and keep the matching platforms and NDK versions. Everything older is a candidate for removal. A project you haven't opened in years can download what it needs again.
Why do NDK versions pile up?
Android Studio installs every NDK version side by side, so projects that pin different versions can each build with their own. Android's documentation also notes that the Android Gradle plugin can install the NDK a project needs by itself, the first time you build it, once you've accepted the NDK's license.
So opening an old project can quietly add a whole NDK version. The catalog's entry for the NDK explains the trade-off: each version is a large download, and versions no project uses stay until you clear them under NDK (Side by side) in the SDK Tools tab.
Emulator system images and virtual devices
The emulator is the other big consumer. It's worth separating its two parts, because they're stored apart and removed in different windows.
Where are a device's files?
Each virtual device is a folder named after it, ending in .avd, inside ~/, with a small settings file of the same name next to it. Android Studio lists the device by that settings file.
The folder holds the device's storage, its virtual SD card and its saved snapshots. Use Show on Disk in the Device Manager to open it, but remove devices with Delete, so the folder and its settings file go together.
What's the difference between a system image and a virtual device?
A system image is a copy of Android for one version, device type and processor, kept in the SDK. A virtual device is one emulator you created from an image, with its own storage, installed apps, settings and saved state, kept in ~/.
Several devices can share one image. Deleting a device leaves the image; uninstalling an image leaves the devices that use it unable to start until you download it again.
How much space does each virtual device take?
Android's system requirements say you might need up to 6 GB of additional storage for each additional virtual device. The emulator's own requirements ask for at least 16 GB of free disk space, and Android Studio with the emulator recommends a solid-state drive with 32 GB or more free.
A device grows as you use it: apps you install on it, their data, its virtual SD card and its saved snapshots all live in its folder.
How do you delete a virtual device?
- Open the Device Manager: choose View › Tool Windows › Device Manager, or from the Welcome screen, More Actions › Virtual Device Manager.
- On the Virtual tab, find the device you no longer use.
- Click its Menu button and choose Delete.
The device and everything on it go: apps, data and settings. The Android Virtual Devices entry rates them Review first for that reason. You can create a new device from the same image, but it starts empty.
Is Wipe Data enough?
Often, yes. Wipe Data, in the same menu, clears a device's user data so it's as it was when new, and keeps the device itself. It's the right move for a device you still use that has filled up with test installs.
What are Quick Boot snapshots, and do they take space?
By default, each virtual device saves a Quick Boot snapshot when you close the emulator, so the next start is faster. Android's documentation says a device can boot up to 10 times faster that way. You can also take any number of general snapshots, and each one is a saved state of the whole device.
Snapshots are kept in the device's folder. To delete one, open the emulator's Snapshots pane, select it and click the delete button. Snapshots become invalid when the emulator, the system image or the device's settings change; the emulator then asks whether to delete them.
To stop saving a Quick Boot snapshot for a device you rarely use, open the Settings tab of the Snapshots pane and set Auto-save current state to Quickboot to No. The device then starts from a cold boot, which is slower.
Can you make new devices smaller?
A little. When you create or edit a device in the Device Manager, its advanced settings include Internal Storage and SD Card sizes. A device that only runs your app rarely needs a large SD card; Android's documentation recommends at least 100 MB if your app uses the camera.
Changing a device's settings resets its saved state, and the next start is a cold boot.
Old Intel images on an Apple silicon Mac
If you moved to an Apple silicon Mac from an Intel one, your old x86 system images and devices may have come along. Android's emulator documentation lists arm64-v8a images as the ones that run with acceleration on Apple silicon, so x86 images there are mostly dead weight.
Create new devices from arm64-v8a images in the Device Manager, then delete the old devices and uninstall the x86 images in the SDK Manager.
Can you keep virtual devices on another drive?
Not from Android Studio's windows. Android's documentation describes an environment variable for the folder where devices are stored, and suggests it when the default location is low on space, but there's no setting for it in Android Studio. Deleting devices you don't use is the simpler fix.
Gradle: caches, Gradle versions and downloaded JDKs
Every Android project builds with Gradle, and Gradle keeps what it downloads in ~/, shared by all your projects.
What's in the .gradle folder?
Item in ~/.gradle | What it holds | Safe to remove? |
|---|---|---|
caches | Downloaded dependencies, the local build cache, generated files | Yes; downloaded again |
wrapper/dists | Copies of Gradle, one per version your projects use | Yes; downloaded again |
daemon | The background process's registry and logs | Its logs, yes |
jdks | JDKs Gradle downloaded for builds that asked for them | Ones no project uses |
gradle.properties | Your global Gradle settings | No |
init.d | Your global initialization scripts | No |
The Gradle caches entry rates the caches folder Safe: Gradle downloads or regenerates anything missing on the next build. That build is slower, and offline builds fail until the dependencies are back.
Does Gradle clean up after itself?
Yes. Gradle's documentation says it checks its caches about once every 24 hours, in the background when its daemon stops. Downloaded files unused for 30 days and files it made itself unused for 7 days are deleted, and so are Gradle versions no project uses any more.
Daemon logs older than 14 days go too, and each project's own cache is cleaned of anything unused for 7 days. So a large ~/ folder mostly reflects the projects you've built in the last month, not years of leftovers.
When is clearing Gradle's caches worth it?
When you've stopped Android work for a while, or you're about to, and need the space now. Gradle's own cleanup only removes what has gone unused for a week or a month, so it won't help today.
Quit Android Studio first, so no build is running, then move ~/ to the Trash in Finder. Leave the rest of the folder.
Which Gradle versions do your projects use?
Each project names its Gradle version in gradle/wrapper/gradle-wrapper.properties, and the wrapper downloads that version into ~/. Projects on different Gradle versions each keep their own copy, and Gradle removes versions that no project has used for a while.
Why do JDKs pile up in .gradle?
When a build asks for a Java version you don't have, Gradle can download one into ~/. Its documentation says these JDKs are never updated automatically, and its cache cleanup doesn't cover them: each new requirement adds one, and old ones stay.
Gradle's documentation says to remove an unneeded one from that folder by hand. Quit Android Studio first, because Gradle's background process remembers where each JDK is.
What about the .m2 folder?
Some Android and Java projects also use Maven's local repository, ~/. The catalog rates it Usually safe: Maven downloads missing libraries on the next build. The exception is artifacts you installed there from your own projects, which come back only when you build and install those projects again.
Android Studio's own caches, logs and old versions
Android Studio is built on JetBrains' IntelliJ platform, and like other JetBrains IDEs it keeps a separate set of folders for every version you run. After a few years of updates, most of them belong to versions you no longer have.
What's in the per-version folders?
The system folder in ~/ holds code indexes, caches and the local history of your edits. The Android Studio caches entry rates it Usually safe: Android Studio rebuilds indexes and caches when they're missing, but local history can't be rebuilt.
Logs in ~/ are safe to remove with Android Studio quit. Settings and plugins in Application Support are your configuration; leave the current version's alone.
How do you remove folders of old versions?
When you run a major version of Android Studio for the first time, it looks for caches, settings, indexes and logs of versions it can't find installed. Its Delete Unused Android Studio Directories dialog then lists their locations, sizes and last-modified dates, and offers to delete them.
If you dismissed that dialog, the folders stay. With Android Studio quit, you can move an old version's folders to the Trash in Finder: its system folder in Caches and its logs folder are safe once that version is gone.
Does Invalidate Caches free space?
A little, briefly. File › Invalidate Caches clears the current version's caches when Android Studio restarts, and they're rebuilt as soon as you open your projects. JetBrains' documentation describes it as a troubleshooting step, not a storage tool.
Its option to clear the file system cache and local history removes local history too, so leave that unchecked unless you're troubleshooting.
Canary, beta and stable side by side
Android lets you install preview versions next to the stable one. Each is a separate app with its own set of folders, and each downloads its own caches and indexes. If you tried a preview and went back to stable, remove the preview app and its folders.
If you installed Android Studio with JetBrains Toolbox, Toolbox handles its updates, can install canary, RC and stable versions in parallel, and can roll back to earlier versions. Check which versions it has installed, and remove the ones you don't use from Toolbox rather than from Finder.
Project build folders and per-project caches
Inside each project, Gradle writes what it builds and some caches of its own. They're easy to forget, because they sit next to your code.
Is it safe to delete a project's build folder?
Mostly. The catalog's entry for Gradle build folders explains that Gradle writes compiled code, APKs, app bundles and test reports into a build folder next to each module's build script, and creates it again on the next build. Your source code isn't affected. In Android projects, these folders often reach several gigabytes.
The catch is release builds. A build folder can hold the app you shipped and the mapping files you need to read crash reports from that release. Keep a copy of those somewhere else before you remove it.
What is the hidden .gradle folder in a project?
Gradle also keeps project-specific caches in a hidden .gradle folder at the project's root, for incremental builds. It's separate from the one in your home folder. Gradle creates it again on the next build and removes parts unused for 7 days by itself.
Kotlin Multiplatform and Flutter
Kotlin Multiplatform projects that build for iPhone download the Kotlin/Native compiler and its components into ~/. It's safe to remove: the next native build downloads it again and is slower.
Flutter apps have their own build folder per project, holding output for every platform you build for, release builds included. If you also build for iPhone, Xcode's files add to all this; the post on why Xcode takes up so much space covers them.
What's safe to remove: a decision table
Everything Android Studio keeps falls into three groups: things that come back by themselves, things you can download again, and things that hold your data or settings.
| Item | Comes back by itself? | What removing it costs | How |
|---|---|---|---|
| Gradle caches and daemon logs | Yes, on the next build | A slower build, a download | Finder, with Android Studio quit |
| Gradle versions in wrapper/dists | Yes, when a project needs one | A download | Finder |
| Android Studio logs | Yes | Old logs for bug reports | Finder |
| Old versions' cache folders | Not needed | Their local history | Leftover-folders dialog, or Finder |
| SDK platforms, build tools, NDK | No, reinstall | A download if a project needs it | SDK Manager |
| System images | No, reinstall | Devices using them won't start | SDK Manager |
| Virtual devices | No | Their apps, data and snapshots | Device Manager |
| Project build folders | Yes, on the next build | A full build; release builds and mapping files | Finder, after saving releases |
What should you never delete?
- The whole .android folder. It holds your virtual devices, the SDK tools' preferences and your debug keystore, which Android Studio creates in
~/to sign debug builds..android - Your debug keystore on its own. Android Studio makes a new one, but with a new certificate, so anything you registered with the old fingerprint needs updating.
- gradle.properties and init.d in .gradle. They're your settings, and they can hold passwords or keys your builds read.
- The SDK folder, in Finder. Uninstall packages in the SDK Manager, so Android Studio's records match what's on disk.
- Release keystores and shipped builds. A release keystore can't be recreated, and a shipped build's mapping files are what make its crash reports readable.
Mistakes to avoid
- Deleting
~/to clear one device. It takes every device with it. Use the Device Manager..android/ avd - Clearing caches while a build runs. Builds in progress can fail. Quit Android Studio first.
- Removing a system image a device still uses. The device can't start until you download the image again.
- Expecting a speed-up. Clearing caches frees space. The next build and the next indexing are slower, not faster.
What does that look like in practice?
Say you've worked on Android for a few years and created a device for each new Android version. Android's guidance of up to 6 GB per extra device means five old devices can account for up to 30 GB, plus their system images in the SDK.
Delete the devices for versions you no longer test in the Device Manager. Then, in the SDK Manager, uninstall the images and platforms for those versions, and NDK versions no project pins. Finally, check Android Studio's caches folder for versions you no longer have.
Removing Android Studio altogether
If you've stopped Android work, most of this has no reason to stay. Removing the app alone frees the least, though, because everything above lives outside it.
What does dragging Android Studio to the Trash leave behind?
Everything in the first table of this post. The SDK, your virtual devices, Gradle's folder, and Android Studio's settings, caches and logs for each version stay where they are, often far larger than the app.
Quit Android Studio and any running emulator first, then move the app from Applications to the Trash. After that, remove the folders you no longer need in Finder, starting with the largest: usually the SDK and the virtual devices. The post on uninstalling Android Studio completely takes each folder in turn, signing keys first.
What should you keep if you might come back?
- Release keystores, shipped builds and their mapping files, for the reasons above.
- Your projects. Their build folders can go; the source can't be recreated.
- gradle.properties, if it holds settings or keys you'd have to find again.
Everything else downloads again the day you reinstall: the SDK through the setup wizard, Gradle and its caches on the first build.
Keep Android Studio from filling your Mac again
Most of Android Studio's growth comes from adding versions and never removing them. A short habit after each upgrade keeps it in check.
Keep one device per version you test
A device per API level you support is plenty for most apps. When you stop supporting a version, delete its device and its image together, so neither outlives the other.
Turn off auto-saved snapshots on devices you rarely use
Quick Boot is worth it on the device you use every day. On devices you start once a month, set Auto-save current state to Quickboot to No in the Snapshots pane's settings, so they don't keep a saved state you'll rarely load.
Tidy up after each Android Studio upgrade
When a new major version starts, read the Delete Unused Android Studio Directories dialog rather than dismissing it. Open the SDK Manager too, with Show Package Details on, and clear build tools and platforms your projects have moved past.
Leave downloads out of Time Machine
The SDK and Gradle's caches change often and can be downloaded again, so backing them up mostly fills your backup disk. To skip them, open System Settings › General › Time Machine, click Options, click the Add button and choose the folders, then click Done.
Apple's documentation for macOS 27 describes these steps, and they're the same in macOS 26. Excluded items still appear in Time Machine's local snapshots on your Mac.
The post on excluding developer folders from Time Machine lists other folders worth leaving out.
Test on a phone when you can
An Android phone connected for debugging needs no system image and no virtual device on your Mac. For everyday testing on one device type, a physical phone saves the emulator's space altogether; keep virtual devices for the versions and screen sizes you don't own.
Let Gradle's cleanup run
Gradle's cleanup runs on its own in the background, so most of the time there's nothing to do. Gradle's documentation also describes shorter retention periods, set in an initialization script in ~/, for Macs with little room.
- Free space for Studio and the emulator, minimum16 GB
- Free space, recommended32 GB
- Each additional virtual device, up to6 GB · Review first
- Gradle, SDK and devices on a busy Mac10–100 GB
The first three are from Android's system requirements. The range is typical on Macs used for Android work, from the research behind the app's catalog; many Macs have less.
For a wider look at everything developer tools keep, see freeing up disk space on a developer's Mac.
How the app does it
Wombit explains Android Studio's folders like everything else on the disk. Select one in the map or the list, and you see what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.
Cleanup lists them by level:
- Gradle's caches, Gradle versions in wrapper/dists, daemon logs, project build folders, project .gradle folders, Kotlin/Native's folder and Android Studio's logs are Safe. They count toward the safe total and start checked, and go to the Trash, where you can put them back.
- Android Studio's per-version caches and emulator system images are Usually safe, so they wait for you to check them.
- Virtual devices are Review first, because each holds apps and data you may want.
- The SDK and NDK are Usually safe too. They're explained with the SDK Manager's steps, and the app leaves removing them to Android Studio.
~/
Library/ Android/ sdk The Android SDK: platforms, build tools, the emulator and other packages used to build and run Android apps.
Usually safe · Explained only: the app shows you how
~/
Library/ Android/ sdk/ system-images Android emulator system images
Copies of Android that the emulator starts from, one for each Android version and device type you've downloaded.
Usually safe · Moves it to the Trash
~/
.android/ avd/ *.avd Android Virtual Devices (AVDs)
Android emulators you created, each with its own storage, installed apps and saved state.
Review first · Moves it to the Trash
~/
.gradle/ caches Dependencies, build cache entries and other files that Gradle keeps for all the Java, Kotlin and Android projects you build.
Safe · Moves it to the Trash
~/
Library/ Caches/ Google/ AndroidStudio* Android Studio's system folder, with indexes, caches and local history, one for each version you've run.
Usually safe · Moves it to the Trash
Seeing all of this is free. Cleanup is PRO, one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
Why is Android Studio using so much storage on my Mac?
Mostly because of what it downloads around the app: SDK platforms, build tools and NDK versions, emulator system images, virtual devices, Gradle's caches and a cache folder for every Android Studio version you've run. Old versions of each stay until you remove them. The SDK Manager and Device Manager are the places to start.
Can I delete the .gradle folder on a Mac?
Its caches folder, yes: Gradle downloads or rebuilds what's missing, and the next build is slower. Don't delete the whole folder, because it also holds your gradle.properties and initialization scripts. Gradle also cleans its own caches, removing files unused for 7 or 30 days.
How do I delete an Android emulator on a Mac?
In Android Studio, open the Device Manager, find the device on the Virtual tab, click its Menu button and choose Delete. Its apps, data and snapshots go with it. The system image it used stays in the SDK until you uninstall it in the SDK Manager.
Is it safe to delete Android system images?
Yes, through the SDK Manager: clear the image under Show Package Details and click Apply. Virtual devices that use it won't start until you download it again. Images for Android versions you no longer test on are the usual candidates.
Where is the Android SDK on a Mac?
Android Studio installs it in the Android folder inside your Library folder, at ~/Library/Android/sdk, unless you chose another location. The SDK Manager shows the folder at the top of its window as Android SDK Location.
What is the .android folder in my home folder?
It's where the Android SDK tools keep their preferences, your virtual devices, in its avd folder, and the debug keystore Android Studio uses to sign debug builds. Remove devices in the Device Manager rather than deleting the folder, which would take every device and your debug keystore with it.
How much free space does Android Studio need on a Mac?
Android's system requirements ask for 8 GB of free space for Android Studio alone, 16 GB with the emulator, and recommend a solid-state drive with 32 GB or more free. Each additional virtual device can need up to 6 GB more.
Can I delete old AndroidStudio folders in Library/Caches/Google?
Folders for versions you no longer have installed, yes, with Android Studio quit. Android Studio also offers to delete them in its Delete Unused Android Studio Directories dialog when you first run a new major version. Leave the current version's folder, or Android Studio will rebuild its indexes and lose its local history.
Sources
- Change Storage settings on Mac · Apple
- Update the IDE and SDK tools · Android Developers
- Create and manage virtual devices · Android Developers
- Start the emulator from snapshots · Android Developers
- Install Android Studio · Android Developers
- Gradle directories · Gradle