Developing applications on the platform Android is often accompanied by the accumulation of a huge number of temporary files, which over time begin to slow down the development environment. If yours Android Studio has started running slowly, freezing during builds, or throwing strange compilation errors, it's likely time for some spring cleaning. Cleaning up a project is not just about removing extra bytes, but a necessary step in maintaining the health of your code and increasing productivity.
In this article we will look in detail at all cleaning methods: from standard menu commands to manually deleting system folders. You will learn which directories you can delete without fear of losing important data, and which you absolutely cannot touch. We will look at both built-in IDE tools and command line methods, which is especially important for automating build processes.
Proper cleaning can not only free up gigabytes of disk space, but also solve many mystical bugs when the code seems to be correct, but the project does not build. Let's start with the simplest and safest method, which is available to every user directly from the app interface.
Standard cleaning through the Build menu
The fastest and safest way to put the project in order is to use the built-in menu commands Build. This method is recommended to be used regularly during the development process, especially after major changes to the module structure or library updates. The system itself will determine which compiled classes are outdated and require rebuilding.
To perform the operation, you need to go to the top menu and select the item Build, and then press Clean Project. This command initiates the removal of all files generated during previous builds. Once the cleanup is complete, it is highly recommended to immediately run the command Rebuild Projectwhich will start the compilation process from scratch, creating a fresh class cache.
⚠️ Attention: The Clean Project command deletes only the output files of the build, but does not affect the cache of the IDE itself or the Gradle system settings. If the problem persists, a deeper cleanup will be required.
Using this method will ensure that you don't accidentally delete important configuration files or source code. However, it is worth understanding that Clean Project does not always solve problems associated with a corrupted IDE index or Gradle cache. In such cases, you have to resort to more radical measures, which we will talk about in the following sections.
Use hotkeys to speed up work: in Windows/Linux this is Ctrl+Shift+A (action search), where you can quickly find the Clean Project command without using the mouse.
Manually deleting the build folder and artifacts
Sometimes automatic cleaning through the menu does not work correctly due to files being blocked by the operating system or frozen processes. In such a situation, the only correct solution is to manually delete the build directories. This gives full control over what exactly is deleted, and allows you to get rid of the “garbage” that the IDE for some reason missed.
The main target is the folder buildwhich is located in the root of each module in your project. This is where compiled .class files, resources, manifests and ready APK or AAB packages are stored. It is also worth paying attention to the folder app/buildif you are working with a standard project structure. Removing these directories is completely safe, since they are generated automatically during the next build.
- 🗑️ Folder
build/in the root of the project - contains common build files. - 🗑️ Folder
app/build/- here are the compiled classes of your applications. - 🗑️ Folder
.gradle/in the root of the project - stores a local cache of Gradle versions for this project.
To perform deletion, close Android Studio, go to your project directory through the file manager and manually delete the specified folders. After this, launch the IDE again. The system will detect the absence of assembly files and automatically start the process Gradle Sync, recreating the necessary structure from scratch.
☑️ Manual project cleanup
Clearing Gradle cache and configurations
System assembly Gradle is a powerful but heavy tool that tends to accumulate huge amounts of cached data. Over time, the cache can become corrupted, resulting in "Corrupted ZIP" errors or endless downloads of dependencies. Clearing the Gradle cache often solves problems that cannot be fixed by standard methods.
The global Gradle cache is usually located in the user's home directory. On Windows this is the path C:\Users\UserName\.gradle\caches, and on macOS and Linux - ~/.gradle/caches. Deleting the contents of this folder will force Gradle to re-download all required dependencies and plugins the next time you run the project. This may take time depending on the speed of your Internet connection.
./gradlew cleanBuildCacheAn alternative and gentler method is to use the command cleanBuildCache via a terminal or the built-in IDE console. This command removes only the assembly cache without affecting loaded libraries, which saves bandwidth. However, to completely reset the build system state, manually deleting the folder caches remains the most reliable option.
⚠️ Warning: If you delete the global Gradle cache (.gradle/caches), you will have to download all libraries again. Make sure that you have a stable Internet connection so as not to interrupt the download process in the middle.
It is also worth checking the file gradle.properties in the root of the project. Sometimes parameters are specified there that may conflict with the current version of the development environment. Resetting Gradle settings to default values can eliminate hidden configuration conflicts.
Where is the Gradle cache stored in different OSes?
In Windows, the cache is located in the %USERPROFILE%\.gradle path, in macOS and Linux - in the home directory ~/.gradle. Deleting this folder is safe, but will require downloading the dependencies again.
Invalidating the cache of Android Studio itself
Problems with performance and correct display of code are not always related to the project or Gradle. Often the culprit is the internal indexing mechanism itself Android Studio. The IDE creates complex indexes for quick search, autocompletion and navigation, which over time can become out of sync with the actual state of files on the disk.
There is a special function Invalidate Caches / Restartto solve this problem. It is located in the menu File (in new versions it may be in the menu with the project icon or File -> Invalidate Caches...). When you select this item, a dialog box opens with several options that allow you to fine-tune the cleaning process.
| Option | Description of action | Impact on the project |
|---|---|---|
| Clear VCS Log caches | Clearing the Git/SVN version history cache | History commits will be rebuilt again |
| Clear downloaded shared indexes | Deleting loaded shared indexes | Will speed up work, but will take loading time |
| Clear file system cache and Local History | Full file system cache reset | Local history of changes will be lost |
| Clear VCS Log caches and indexes | Comprehensive clearing of VCS caches | Full reset of version control system data |
The most radical option is checking the item Clear file system cache and Local History. This will delete all local change history that the IDE stores independently of Git. Use this option only as a last resort, when other methods have not helped, and you are sure that all important changes are committed to the repository.
IDE cache invalidation solves 90% of problems with interface "glitches", incorrect syntax highlighting and lack of autocompletion, without affecting the project source code.
Deleting hidden system folders .idea and .gradle
If none of the previous methods brought results, the configuration files of the project itself may be damaged. Hidden folders .idea and .gradleare stored in the project root, which contain project settings, launch schemes and local configurations. Deleting them is equivalent to creating a new project with linking existing code.
The folder .idea contains settings Android Studiospecific to this project: window layout, code style settings, paths to the SDK and much more. Deleting this folder will reset all project settings to their default state. The next time you open the IDE, it will regenerate these files, which often eliminates configuration errors caused by incorrect studio updates or project transfers.
- 📁 Folder
.idea/— stores settings for the project and IDE modules. - 📁 Folder
.gradle/(in project root)—stores local build settings. - 📁 File
local.properties—contains the path to the SDK on your computer.
It is important to note that the file local.properties you should not commit to the version control system, since the paths differ for different developers. When you delete a folder .idea this file may also be deleted or reset. You will have to re-specify the path to the Android SDK in the project settings if the IDE does not find it automatically.
⚠️ Warning: Before deleting the .idea folder, make sure you have a backup copy of the settings if you have carefully set up code inspections or launch schemes. After deletion, all individual project settings will be lost.
Cleaning up via the command line and terminal
For advanced users and those who prefer to work with the terminal, there is a set of commands that allow you to manage project cleanup without using a graphical interface. This is especially convenient when setting up CI/CD pipelines or when working on servers without a graphical shell. Gradle commands provide a flexible tool for managing the build lifecycle.
The main command for cleanup is ./gradlew clean (on Windows gradlew.bat clean). It is similar to the action Clean Project in the menu, but is performed faster and more clearly in the console. For deeper cleaning, you can use the task cleanBuildCachethat we mentioned earlier. Combining these tasks allows you to achieve maximum effect.
./gradlew clean cleanBuildCache --refresh-dependenciesThe flag --refresh-dependencies causes Gradle to ignore the dependency cache and check remote repositories for updates. This is useful if you suspect that a downloaded library is corrupt or out of date. However, using this flag significantly slows down the build process, so use it only when necessary.
You can also delete folders manually through the terminal using system commands. For example, on Linux or macOS, the command rm -rf app/build will instantly delete the build directory. In Windows PowerShell the analogue will be Remove-Item -Recurse -Force app\build. Such methods give full control, but require care not to remove unnecessary things.
Add aliases for cleanup commands to your shell profile (.bashrc or .zshrc) to clean the project with one short command, for example: alias androidclean='./gradlew clean cleanBuildCache'.
Frequently asked questions and problems with cleaning
Is it safe to delete the .gradle folder in your home directory?
Yes, it is safe. This folder stores only downloaded dependencies and cache. The next time you build the project, Gradle will automatically download everything it needs again. The only negative is that it will take time and Internet traffic.
Why does the project take a long time to open after cleaning?
After deep cleaning, Android Studio is forced to re-index all project files, rebuild the dependency graph and download libraries. This is normal behavior that is observed only on the first launch after cleaning.
What if the error persists even after a complete cleanup?
If cleaning did not help, try updating Android Studio itself to the latest version, checking the Gradle version of the plugin in the build.gradle file, or creating a new empty project and transferring the source code of the modules there.
Is it possible to add cleanup folders to .gitignore?
The build, .gradle (local) and .idea folders should already be in the standard .gitignore for Android projects. Never commit generated files and local IDE settings to the repository.
How to clear the cache of a specific module, and not the entire project?
Use the command ./gradlew :app:clean, replacing app with the name of the desired module. This will delete the build files only for the specified module, leaving the rest untouched.