Android Studio taking up too much space: SDK, emulators and AVDs

Part of: Mac disk cleanup for developers: every cache, what it costs to rebuild (Developers)

Android Studio itself is not the big part. The space goes to the SDK, the emulator and its virtual devices, and the Gradle cache. You can remove most of it, but the virtual devices hold data, so decide which ones you use first.

Quit Android Studio and any running emulator before you remove anything.

The folders that matter

On a Mac, the defaults are:

• ~/Library/Android/sdk: the Android SDK. It holds platforms, build tools, the emulator program and system images. A system image is the Android version an emulator runs.
• ~/.android/avd: the virtual devices. AVD means Android Virtual Device, a pretend phone on your Mac. Each one has its own disk image.
• ~/.gradle: Gradle User Home, containing cache data and user configuration. Downloaded dependencies live in ~/.gradle/caches; see the Gradle guide.

Check the sizes with Terminal:

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

The first command lists each part of the SDK. On the Mac used to check this article, the virtual devices were the largest single item, ahead of the emulator program and the build tools. Your Mac will differ, so look before you decide.

Safe, risky, never

• Safe: virtual devices you never open, and SDK platforms or system images for Android versions you no longer target. Cost: you create the device again or download the image again.
• Risky: a virtual device that holds test data, a signed-in account or a configured state. Removing it removes that state. Also risky: removing an SDK platform that a project still builds against. The project will ask you to install it again.
• Never: do not delete files inside ~/.android by hand if they are not avd. The folder also holds keys, including the debug signing key. Losing it breaks your link to apps signed with it.

Remove virtual devices

Open Android Studio and use the Device Manager to list your devices. Remove the ones you do not use. Let the tool remove them: it deletes the device’s definition and its disk image together. If you delete files in avd by hand, the tool can end up listing a device that no longer exists.

Each removed device frees its disk image. A device you need again takes minutes to create, plus a system image download if you removed that too.

Remove SDK parts you do not use

Android Studio’s SDK Manager lists installed platforms, system images and tools, and lets you untick and remove them. Keep the platform your projects compile against, plus the build tools they use. Old platforms and system images for versions you no longer test on are the usual savings.

Removal costs a download if you need the part again. The download size is shown in the SDK Manager before you install.

Cold boot snapshots

Emulators can keep a saved state, called a snapshot, so they start in seconds. Snapshots live inside a device’s folder and add to its size. If a device is large and you do not mind a slower start, you can turn snapshots off in the device’s settings. Do not delete snapshot files by hand.

Gradle and Maven caches

Building Android apps downloads libraries into ~/.gradle/caches. Remove only identified cache data when you can afford the re-download; do not delete the whole Gradle User Home. Preserve gradle.properties, init.gradle(.kts), init.d and any other user configuration. See how to clear the Gradle cache. If you also build Java projects with Maven, downloaded dependencies live in ~/.m2/repository. Preserve ~/.m2/settings.xml and any other Maven configuration; see where the .m2 folder is.

The wider list of developer folders is in the developer cleanup guide.

Worked example: what is in ~/.android

Before you remove anything, list the folder. This command only reads:

ls -a ~/.android

On the Mac used to check this article, it showed an avd folder, a cache folder, adbkey and adbkey.pub, a debug.keystore file and a few small settings files. Only avd and cache are about space. The key files are tiny, and they are the reason for the “never” rule above.

Now look inside avd:

ls ~/.android/avd

On that Mac it listed one virtual device. A device appears twice: as a folder that ends in .avd, and as an .ini file with the same name. The folder holds the disk image. The .ini file only points to it. That is why a hand delete is easy to get wrong. Remove one half and the tool shows a broken device. Use Device Manager so both go together.

If something goes wrong

• Device Manager lists a device that no longer starts. You probably deleted part of it by hand. Remove the broken entry in Device Manager, then create the device again.
• A project asks for a platform or system image you removed. Install it again in SDK Manager. This costs a download and nothing else.
• The emulator will not start. Quit it fully, then start it again. If the device still fails, create a new one and remove the broken one in Device Manager.
• You see little change in free space. Empty the Trash, and check that you removed the large item. A system image is often larger than the tools around it.

When not to clean

Skip this if you are about to submit a build, or if a device holds a signed-in test account that took you an hour to set up. Wait until you are done, or note the setup steps first. The sizes will still be there tomorrow.

See the sizes with DiskJoy

DiskJoy is our product. Its scan reads your disk and shows how large the SDK, ~/.android and ~/.gradle are, without changing anything. Cleanup is not built yet, so DiskJoy does not remove any of these folders today.

Quick checklist

1. Run du -sh on the three folders above.
2. Remove virtual devices through Device Manager.
3. Remove unused SDK platforms and system images through SDK Manager.
4. Clear only identified Gradle cache data if you can afford the re-download; keep user settings and init scripts.
5. Leave the keys in ~/.android alone.