Extremely long build with Gradle (Android Studio)

Question

I'm not quite sure why Android Studio is slower than the command line, but you can speed up your builds by turning on incremental dexing. In your module's build file, add this option to your android block:

dexOptions {
    incremental true
}

In that dexOptions block you can also specify the heap size for the dex process, for example:

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

These options are taken from a thread on the adt-dev mailing list (https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ) which has a little more context.

Our team was facing the same issue. Our project exceeds the method limit for dex(>65k). So, in out library project we put below options in build.gradle:

dexOptions {
    jumboMode = true
    preDexLibraries = false
}

In our project build.gradle:

 dexOptions {
    jumboMode = true
//  incremental true
}

previously we had incremental true. after commenting it its taking around 20s to run as compared to 2mins 30 seconds. I don't know this may solve your problem. but it can help to others. :)

Disclaimer: This isn't a solution - it's a statement that there is no solution with relevant link sources to prove it.

Since all answers here do not solve a problem that has been lingering since 2014, I'm gonna go ahead and post a couple of links which describe a very simillar problem and present OS-specific tweaks that might or might not help, since OP did not seem to specify it, and solutions vary a lot across them.

First is the actual AOSP bug-tracker issue referring to parallelization, with a lot of relevant stuff, still open and still with a lot of people complaining as off version 2.2.1. I like the guy who notes the issue (a high-priotity one at that) id including "666" not being a coincidence. The way most people describe music programs and mouse movement stuttering during builds feels like looking into a mirror...

You should note people report good stuff with process lasso for Windows, while I see none really reporting anything good with renice'ing or cpu-limiting in *nix variants.

This guy (who states he doesn't use gradle) actually presents some very nice stuff in Ask Ubuntu, that unfortunately doesn't work in my case.

Here is another alternative that limits threads of gradle execution, but that didn't really improve in my scenario probably due to what somebody says on another link about studio spawning multiple gradle instances (while the parameter only affects one instance's parallelism).

Note that this all goes back to the original "666", high-priority issue...

Personally I couldn't test many of the solutions because I work on a managed (no root privs) Ubuntu machine and can't apt-get/renice, but I can tell you I have an i7-4770, 8GB RAM and a hybrid SSD, and I have this problem even after a lot of memory and gradle tweaks over the years. It is a tantalizing issue, and I can't understand how Google hasn't committed the necessary human resources to the gradle project to fix something that is at the core of development for the most important platform they build.

One thing to note on my environment is: I work in a multi-dependency studio project, with about 10 subprojects, all of them building on their own and filling up the gradle pipeline.