Gradle Build too long

Question

Gradle build now takes too long (literally it does not complete building after running for like 1 hour) after enabling MultiDex. I followed the steps given at https://developer.android.com/studio/build/multidex.html site to configure MultiDex in app.

Below is an excerpt from my gradle console.

:app:compileDevelopmentDebugNdk UP-TO-DATE
:app:compileDevelopmentDebugSources
:app:mergeDevelopmentDebugShaders UP-TO-DATE
:app:compileDevelopmentDebugShaders UP-TO-DATE
:app:generateDevelopmentDebugAssets UP-TO-DATE
:app:mergeDevelopmentDebugAssets UP-TO-DATE
:app:unzipJacocoAgent UP-TO-DATE
:app:transformClassesWithJacocoForDevelopmentDebug UP-TO-DATE
:app:transformClassesWithDexForDevelopmentDebug

the last task :app:transformClassesWithDexForDevelopmentDebug is the one where the gradle console stops. Any help would be appreciated. I also need to test the app in pre-lollipop devices.

Edit

The problem only occurs when I test my app in a pre-lollipop test device. Building for main test device seems to work fine. It takes 8.12 seconds while building for Nexus 6P. But I want to test for pre-lollipop devices too.

Edit 2

As per @Gillis's advice I am attaching my stacktrace

10:19:10.558 [DEBUG] [org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
10:19:10.558 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
10:19:20.555 [DEBUG] [org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
10:19:20.560 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
10:19:20.560 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
10:19:20.561 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
10:19:20.561 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
10:19:20.561 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
10:19:20.561 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.

I have tried removing my /home/.gradle folder too but still no luck. Clearly there is a loop in acquiring the lock.

Also I am attaching my jstacktrace too

"File lock request listener" #27 prio=5 os_prio=31 tid=0x00007fb9b2c20800 nid=0x5d07 runnable [0x0000700001961000]
   java.lang.Thread.State: RUNNABLE
        at java.net.PlainDatagramSocketImpl.receive0(Native Method)
        - locked <0x00000006c026d670> (a java.net.PlainDatagramSocketImpl)
        at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
        - locked <0x00000006c026d670> (a java.net.PlainDatagramSocketImpl)
        at java.net.DatagramSocket.receive(DatagramSocket.java:812)
        - locked <0x00000006c0bc5df0> (a java.net.DatagramPacket)
        - locked <0x00000006c026d630> (a java.net.DatagramSocket)
        at org.gradle.cache.internal.FileLockCommunicator.receive(FileLockCommunicator.java:60)
        at org.gradle.cache.internal.locklistener.DefaultFileLockContentionHandler$1.doRun(DefaultFileLockContentionHandler.java:67)
        at org.gradle.cache.internal.locklistener.DefaultFileLockContentionHandler$1.run(DefaultFileLockContentionHandler.java:54)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
        at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

please refer this pastebin for complete log.

for question like *Compilation takes too long* the answer is simple ... buy better PC/Mac — Selvin, Oct 04 '16 at 10:31
iMac (27-inch, Late 2012) 3.2 GHz Intel Core i5, 8 GB 1600 MHz DDR3 , NVIDIA GeForce GTX 675MX 1024 MB — Ashik Vetrivelu, Oct 04 '16 at 10:32
As @Selvin says if your pc configuration is low then its normal to take time but i assume its not that low that it would take hour to complete build even in my dual core it complete within 1 or 2 min. — androidXP, Oct 04 '16 at 10:33
@androidXP I clearly stated I tried using MultiDex as I had dex overflow error earlier with number of methods exceeding 65k. I used a significant amount of libraries. — Ashik Vetrivelu, Oct 04 '16 at 10:38
believe it or not the problem is cuz of your internet connection check offline work in settings->Buildtools->Gradle and try again. — Amir Ziarati, Oct 04 '16 at 10:58
I've tried that too. Its a multi-dex assembly issue. Pre-Lollipop does not have ART compiler and Assembly is done in a bit different way. But still the time taken is way too high. — Ashik Vetrivelu, Oct 04 '16 at 11:49

score 5 · Accepted Answer · answered Oct 05 '16 at 05:21

5

Thanks for your much appreciated help. I solved this issue. Apparently the issue was because (I suppose that) the JaCoCo was dexing along with my class dexing and was issuing a locks. I fixed this by removing the testCoverageEnabled=true line in my app's build.gradle.

In case any of you guys run into similar issue. Create two build flavours (prod and development) and add the line testCoverageEnable=true only for development flavor and set it to false else where. Also ensure that your development has the minSdkVersion set to 21 (Lollipop) as the dexing is done for ART and basically you won't be running into this issue.

answered Oct 05 '16 at 05:21

Ashik Vetrivelu

1,021
1
9
24

But if you remove "testCoverageEnable", you cannot get test coverage report, right? – Richard LIANG Feb 07 '17 at 03:51
create multiple flavour and enable testCoverage for post lollipop versions. – Ashik Vetrivelu Feb 07 '17 at 08:24
this solution saved my day – 楊惟鈞 Sep 07 '17 at 11:09
Thnaks a lot, I was struggling for couple of days to solve this. Though sometimes reason may be different, I would suggest to check this option first if this line is there in gradle file. – PK Gupta Sep 13 '17 at 09:35
Though build issue went away, but not able to get coverage report. minSdkVersion 21 not working. Also product flavors is not recognizing the word "testCoverageEnabled". – PK Gupta Sep 18 '17 at 13:21

score 1 · Answer 2 · answered Oct 04 '16 at 11:57

1

Apart from all the gradle tweaks given in other answers, you can also do something like end the gradle process time to time. In my experience doing that and starting a fresh build solves the issue.

answered Oct 04 '16 at 11:57

YakuZa

516
7
12

score 1 · Answer 3 · answered Oct 04 '16 at 12:06

1

go to your app folder in your console and run:

./gradlew build --debug

this gives you a lot of information what goes wrong. usually when gradle hangs it is caused by an external dependency which cannot be retreived.

You could try enabling offline mode in android studio to see if this is really the issue.

answered Oct 04 '16 at 12:06

Gillis Haasnoot

2,229
1
19
23

Hey man thanks for your advice. I have attached my debug log and stacktrace too. It seems there is a loop in acquiring the wake lock. – Ashik Vetrivelu Oct 05 '16 at 04:53

score 0 · Answer 4 · answered Oct 04 '16 at 10:38

0

Try this

    android {
        compileSdkVersion 24
        buildToolsVersion "24.0.0"

        dexOptions {
            javaMaxHeapSize "4g"
        }
        ....
    }

answered Oct 04 '16 at 10:38

Eren Utku

1,731
1
18
27

Tried it and no luck. – Ashik Vetrivelu Oct 04 '16 at 10:39
`org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m` this is my gradle properties – Ashik Vetrivelu Oct 04 '16 at 10:39
If these are not works for your, try clean install android studio. – Eren Utku Oct 04 '16 at 10:49

score 0 · Answer 5 · answered Oct 04 '16 at 10:43

0

First Make sure your gradle is Up-To-Date also android studio After update delete invalid cache and restart then at last in Global Gradle Setting check "Offline Work" its work for me too give it a try.

answered Oct 04 '16 at 10:43

androidXP

1,692
3
27
58

I've tried that too. I am using gradle version 3.1 and buildTools version 2.2 I've tried with offline work enabled too – Ashik Vetrivelu Oct 04 '16 at 10:47
I have an average if not fast internet. So regularly my build's won't take more than 12 seconds. (by build I meant with syncing). My internet speed is 200Mbps which I think is enough for downloading all dependencies in a flash. But to be on safe side I have also tried with offline mode on. – Ashik Vetrivelu Oct 04 '16 at 11:46

score 0 · Answer 6 · answered Oct 04 '16 at 11:54

A few tips to increase the Gradle task execution performance:

Gradle Daemon You can decrease Gradle’s startup time (on my computer down to two seconds) if you tell Gradle to use a daemon to build:

org.gradle.daemon=true

Parallel Project Execution This can really make a significant difference if you are building a very complex project with many sub-module dependencies:

org.gradle.parallel=true

Global gradle.properties

The properties defined in the property file in our home directory take precedence over the properties defined in the file in our project directory. The reasoning behind this is that you want to avoid using the Gradle daemon on your build servers, where startup time is less important than memory consumption:

/Users/~/.gradle/gradle.properties

like this

score 0 · Answer 7 · answered Jun 06 '20 at 17:35

0

You can use the exit(0); command at the end of your program and it should quit out of this loop

answered Jun 06 '20 at 17:35

Mosrod

67
9

Gradle Build too long

7 Answers7

Linked