Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
400 views
in Technique[技术] by (71.8m points)

android - Gradle Build too long

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.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...