I'm trying to use Android Studio, and the first time I boot it up, it takes like 45 MINUTES to compile... If I don't quit the application, it is okay - each subsequent compilation/running the app will take around 45 seconds.
I've tried to check some of my caches: there's a .gradle/caches
folder in my home directory, and it's contains 123 MB.
There's also a .gradle
folder in my project folder... one of the taskArtifacts
was like 200 MB. I'm scared to just randomly nuke them both. What parts of the folders are safe to delete?
Is there a better explanation for why my Android Studio is taking forever to run the gradle assemble
task upon first time loading the application?
Do I also have to clear the intellij cache too?
Compiler -> Gradle
to not Use in-process build
. nothing to do with the cache
./gradlew clean build --no-build-cache
will force a project build without using the build cache.
Gradle cache is located at
On Windows: %USERPROFILE%\.gradle\caches
On Mac / UNIX: ~/.gradle/caches/
You can browse to these directory and manually delete it or run
rm -r $HOME/.gradle/caches/
on UNIX system. Run this command will also force to download dependencies.
UPDATE
Clear the Android build cache of current project
NOTE: Android Studio's File > Invalidate Caches / Restart
doesn't clear the Android build cache, so you'll have to clean it separately.
On Windows:
gradlew cleanBuildCache
On Mac or UNIX:
./gradlew cleanBuildCache
UPDATE 2
This article Put your Android Studio on a diet gives more details on Android Studio caches
As @Bradford20000 pointed out in the comments, there might be a gradle.properties
file as well as global gradle scripts located under $HOME/.gradle
. In such case special attention must be paid when deleting the content of this directory.
The .gradle/caches
directory holds the Gradle
build cache. So if you have any error about build cache, you can delete it.
The --no-build-cache option will run gradle without the build cache.
Daemon on MS Windows If you're on Windows, you'll need to kill the daemon before it allows you to clear those directories. See Kill all Gradle Daemons Regardless Version? for more info.
UPDATE
cleanBuildCache
no longer works.
Android Gradle plugin now utilizes Gradle cache feature
https://guides.gradle.org/using-build-cache/
TO CLEAR CACHE Clean the cache directory to avoid any hits from previous builds rm -rf $GRADLE_HOME/caches/build-cache-*
https://guides.gradle.org/using-build-cache/#caching_android_projects
Other digressions: see here (including edits).
=== OBSOLETE INFO ===
Newest solution using Gradle task:
cleanBuildCache
Available via Android plugin for Gradle, revision 2.3.0 (February 2017)
Dependencies:
Gradle 3.3 or higher. Build Tools 25.0.0 or higher.
More info at:
https://developer.android.com/studio/build/build-cache.html#clear_the_build_cache
Background
Build cache Stores certain outputs that the Android plugin generates when building your project (such as unpackaged AARs and pre-dexed remote dependencies). Your clean builds are much faster while using the cache because the build system can simply reuse those cached files during subsequent builds, instead of recreating them. Projects using Android plugin 2.3.0 and higher use the build cache by default. To learn more, read Improve Build Speed with Build Cache.
NOTE: The cleanBuildCache task is not available if you disable the build cache.
USAGE
Windows:
gradlew cleanBuildCache
Linux / Mac:
gradle cleanBuildCache
Android Studio / IntelliJ:
gradle tab (default on right) select and run the task or add it via the configuration window
NOTE: gradle
/ gradlew
are system specific files containing scripts. Please see the related system info how to execute the scripts:
Linux
Windows
Mac
Take care with gradle daemon, you have to stop it before clear and re-run gradle.
Stop first daemon:
./gradlew --stop
Clean cache using:
rm -rf ~/.gradle/caches/
Run again you compilation
./gradlew --stop
this line did everything.
The gradle daemon also creates a many large text files of every single build log. They are stored here:
~/.gradle/daemon/X.X/daemon-XXXX.out.log
"X.X" is the gradle version in use, like "4.4", and "XXXX" are just random numbers, like "1234".
The total size can grow to several hundred MB in just a few months. There is no way to disable the logging, and the files are not automatically deleted and they do not really need to be retained.
But you can create a small gradle task to automatically delete them, and free up lots of disk space:
Add this to your app/build.gradle
:
android {
buildTypes {
...
}
// Delete large build log files from ~/.gradle/daemon/X.X/daemon-XXX.out.log
// Source: https://discuss.gradle.org/t/gradle-daemon-produces-a-lot-of-logs/9905
def gradle = project.getGradle()
new File("${gradle.getGradleUserHomeDir().getAbsolutePath()}/daemon/${gradle.getGradleVersion()}").listFiles().each {
if (it.getName().endsWith('.out.log')) {
// println("Deleting gradle log file: $it") // Optional debug output
it.delete()
}
}
}
To see which files are being deleted, you can see the debug output in Android Studio -> View -> Tool Windows -> Build. Then press "Toggle View" button on that window to show the text output.
Note that a Gradle Sync or any Gradle Build will trigger the file deletions.
A better way would be to automatically move the files to the Trash/Recycle Bin, or at least copy them to a Trash folder first. But I don't know how to do that.
there seems to be incorrect info posted here. some people report on how to clear the Android builder cache (with task cleanBuildCache
) but do not seem to realize that said cache is independent of Gradle's build cache, AFAIK.
my understanding is that Android's cache predates (and inspired) Gradle's, but i could be wrong. whether the Android builder will be/was updated to use Gradle's cache and retire its own, i do not know.
EDIT: the Android builder cache is obsolete and has been eliminated. the Android Gradle plugin now uses Gradle's build cache instead. to control this cache you must now interact with Gradle's generic cache infrastructure.
TIP: search for Gradle's cache help online without mentioning the keyword 'android' to get help for the currently relevant cache.
EDIT 2: due to tir38's question in a comment below, i am testing using an Android Gradle plugin v3.4.2 project. the gradle cache is enabled by org.gradle.caching=true
in gradle.properties
. i do a couple of clean build
and the second time most tasks show FROM-CACHE
as their status, showing that the cache is working.
surprisingly, i have a cleanBuildCache
gradle task and a <user-home>/.android/build-cache/3.4.2/
directory, both hinting the existence of an Android builder cache.
i execute cleanBuildCache
and the 3.4.2/
directory is gone. next i do another clean build
:
nothing changed: most tasks show FROM-CACHE as their status and the build completed at cache-enabled speeds.
the 3.4.2/ directory is recreated.
the 3.4.2/ directory is empty (save for 2 hidden, zero length marker files).
conclusions:
caching of all normal Android builder tasks is handled by Gradle. executing cleanBuildCache does not clear or affect the build cache in any way. there is still an Android builder cache there. this could be vestigial code that the Android build team forgot to remove, or it could actually cache something strange that for whatever reason has not or cannot be ported to using the Gradle cache. (the 'cannot' option being highly improvable, IMHO.)
next, i disable the Gradle cache by removing org.gradle.caching=true
from gradle.properties
and i try a couple of clean build
:
the builds are slow.
all tasks show their status as being executed and not cached or up to date.
the 3.4.2/ directory continues to be empty.
more conclusions:
there is no Android builder cache fallback for when the Gradle cache fails to hit. the Android builder cache, at least for common tasks, has indeed been eliminated as i stated before. the relevant android doc contains outdated info. in particular the cache is not enabled by default as stated there, and the Gradle cache has to be enabled manually.
EDIT 3: user tir38 confirmed that the Android builder cache is obsolete and has been eliminated with this find. tir38 also created this issue. thanks!
3.4.2/
dir. 2. presence of cleanBuildCache
task 3. disabling gradle build cache and rebuilding didn't show any evidence of android tasks hitting cache.
My ~/.gradle/caches/
folder was using 14G.
After using the following solution, it went from 14G to 1.7G.
$ rm -rf ~/.gradle/caches/transforms-*
$ rm -rf ~/.gradle/caches/build-cache-*
Bonus:
This command shows you in detail the used cache space
$ sudo du -ah --max-depth 1 ~/.gradle/caches/ | sort -hr
This article Put your Android Studio on a diet helped a lot as recommended here
For those looking for a quick fix press on: File
> Invalidate Caches Restart
To clean a cache for specific project/jar:
Find all the cache files related to that project
find ~/.gradle/caches -name yourproject
The above command will return all the cache files related to yourproject
rm -rf <each file returned>
You need to pass the path of the cache file to the above command.
gradle clean install
Finally to pull latest artifacts
Update:
One liner to delete the cache:
for file in `find ~/.gradle/caches -name yourprojectartifactid`; do `rm -rf $file`; done
Latest command:
--no-build-cache
Found at: https://docs.gradle.org/current/userguide/build_cache.html Works perfectly for a command like:
./gradlew SomeApp:installDebug --no-build-cache
In android studio open View > Tool Windows > Terminal and execute the following commands
On Windows:
gradlew cleanBuildCache
On Mac or Linux:
./gradlew cleanBuildCache
if you want to disable the cache from your project add this into the gradle build properties
(Warning: this may slow your PC performance if there is no cache than same time will consume after every time during the run app)
android.enableBuildCache=false
To clear your gradle cache in android studio:
open terminal and run gradlew clean
Success story sharing
rm -rf ~/.gradle/caches/build-cache-1
instead. if you need to have gradle re download dependencies invoke the build with --refresh-dependenciesgradlew clean cleanBuildCache