Obsolete
Status Update
No update yet.
Comments
ch...@google.com
can you share your android studio version
st...@google.com
Is this happening with Studio 3.0?
pa...@google.com
Note: This worked for me on Windows 7 Pro 32-bit (with Android Studio 2.3.3). Seems like an issue with adt-branding module (which should contain the "/idea/AndroidStudioApplicationInfo.xml" resource).
ja...@google.com
Hi, also happened on Mac Book Pro 15 retina mi-2015
MacOs Sierra 10.12.6
Android Studio 2.3.3
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
MacOs Sierra 10.12.6
Android Studio 2.3.3
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
be...@google.com
Thank you for this feedback. Your feedback helps make sure Android development tools are great! Given your issues has been resolved I am closing this issue.
ja...@google.com
Lowering priority as QA can't repro this.
em...@gmail.com
Hi guys. As the initial reporter, I will attempt the three steps outlined in
em...@gmail.com
An interesting thing I just noticed. To recap, the issue is that gradle hangs if I run the command `./gradlew clean assembleDebugAndroidTest`.
However, it only hangs if there is an attached device. If nothing is attached, it runs just fine.
That said, here are the results of my experiments:
(1) `sudo jmap -heap <pid>`
```
tonyrobalik@Tonys-MacBook-Pro:/workspace/project$
jps
29650
33330 GradleWrapperMain
33273 GradleDaemon
33438 Jps
tonyrobalik@Tonys-MacBook-Pro:/workspace/project$
sudo jmap -heap 33273
Password:
Attaching to process ID 33273, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.92-b14
using thread-local object allocation.
Parallel GC with 8 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 5368709120 (5120.0MB)
NewSize = 89128960 (85.0MB)
MaxNewSize = 1789394944 (1706.5MB)
OldSize = 179306496 (171.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 1751121920 (1670.0MB)
used = 1470944112 (1402.8016204833984MB)
free = 280177808 (267.19837951660156MB)
84.00009703493404% used
From Space:
capacity = 12582912 (12.0MB)
used = 229376 (0.21875MB)
free = 12353536 (11.78125MB)
1.8229166666666667% used
To Space:
capacity = 11534336 (11.0MB)
used = 0 (0.0MB)
free = 11534336 (11.0MB)
0.0% used
PS Old Generation
capacity = 819986432 (782.0MB)
used = 432212952 (412.19039154052734MB)
free = 387773480 (369.80960845947266MB)
52.70976873919787% used
86310 interned Strings occupying 10037384 bytes.
```
(2) Increase -Xmx heap size in gradle.properties file.
My heap size is currently set as follows: `org.gradle.jvmargs=-Xmx5120M`
How large should I set it? I just tried 10000M, and it still didn’t work.
(3) In build.gradle, set `android { dexOptions.dexInProcess = false }`
Same result.
However, it only hangs if there is an attached device. If nothing is attached, it runs just fine.
That said, here are the results of my experiments:
(1) `sudo jmap -heap <pid>`
```
tonyrobalik@Tonys-MacBook-Pro:/workspace/project$
jps
29650
33330 GradleWrapperMain
33273 GradleDaemon
33438 Jps
tonyrobalik@Tonys-MacBook-Pro:/workspace/project$
sudo jmap -heap 33273
Password:
Attaching to process ID 33273, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.92-b14
using thread-local object allocation.
Parallel GC with 8 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 5368709120 (5120.0MB)
NewSize = 89128960 (85.0MB)
MaxNewSize = 1789394944 (1706.5MB)
OldSize = 179306496 (171.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 1751121920 (1670.0MB)
used = 1470944112 (1402.8016204833984MB)
free = 280177808 (267.19837951660156MB)
84.00009703493404% used
From Space:
capacity = 12582912 (12.0MB)
used = 229376 (0.21875MB)
free = 12353536 (11.78125MB)
1.8229166666666667% used
To Space:
capacity = 11534336 (11.0MB)
used = 0 (0.0MB)
free = 11534336 (11.0MB)
0.0% used
PS Old Generation
capacity = 819986432 (782.0MB)
used = 432212952 (412.19039154052734MB)
free = 387773480 (369.80960845947266MB)
52.70976873919787% used
86310 interned Strings occupying 10037384 bytes.
```
(2) Increase -Xmx heap size in gradle.properties file.
My heap size is currently set as follows: `org.gradle.jvmargs=-Xmx5120M`
How large should I set it? I just tried 10000M, and it still didn’t work.
(3) In build.gradle, set `android { dexOptions.dexInProcess = false }`
Same result.
la...@gmail.com
Hello,
I'm currently experiencing the exact same issue on my project.
Nevertheless I've noticed that the `transformClassesWithDexForDebug` is stuck only when I set the `testCoverageEnabled` flag to true on this build type. If the flag is set to false, everything is back to normal.
So I'm wondering if it could be related to jacoco.
Unfortunately I wasn't able to reproduce the issue on a simple project to provide an example. The project which is failing is also using multidex support.
I would be glad to help, so please tell me if you need more information.
I'm currently experiencing the exact same issue on my project.
Nevertheless I've noticed that the `transformClassesWithDexForDebug` is stuck only when I set the `testCoverageEnabled` flag to true on this build type. If the flag is set to false, everything is back to normal.
So I'm wondering if it could be related to jacoco.
Unfortunately I wasn't able to reproduce the issue on a simple project to provide an example. The project which is failing is also using multidex support.
I would be glad to help, so please tell me if you need more information.
ja...@google.com
Can you guys please try this on 2.2 Beta 3, and let us know if this repros?
Download link:http://tools.android.com/download/studio/canary/latest/
Download link:
je...@gmail.com
[Comment deleted]
je...@gmail.com
I'm also experiencing the same issue. I verified that the behavior has not changed with 2.2 Beta 3. I am able to get around the issue by enabling Instant Run. My builds are stuck at the transformClassesWithDexForDebug step when Instant Run is disabled though.
la...@gmail.com
Hello,
I tried to update to 2.2.0-beta3 and I kept having the same issue.
After digging into it, I found out that one of our dependencies was the root cause of this stuck build. I was using an outdated version of Crashlytics (2.5.5), upgrading this dependency to 2.6.2 solved everything, for the gradle buildtools 2.1.3, 2.2.0-beta2 and 2.2.0-beta3.
I tried to update to 2.2.0-beta3 and I kept having the same issue.
After digging into it, I found out that one of our dependencies was the root cause of this stuck build. I was using an outdated version of Crashlytics (2.5.5), upgrading this dependency to 2.6.2 solved everything, for the gradle buildtools 2.1.3, 2.2.0-beta2 and 2.2.0-beta3.
em...@gmail.com
How did you "dig into it"? Would you please explain how you discovered it was one of your dependencies? I have a complex build and don't really want to disable one dependency after another trying to test this idea. Btw, I'm not using Crashlytics. Thanks!
la...@gmail.com
My answer will probably be disappointing, sorry.
I created a new project to try to reproduce the issue, step by step.
My project uses multidex so I just generated some classes with a lot of method to reach dex limit.
It built without any problem so then I added one espresso and one robolectric test.
Still no problem.
I already tried to disable some of the gradle plugins we used in our app, I knew it wasn't one of them breaking the build.
So finally... I imported all of our dependencies one by one. It was blocking during the compilation process they were kind of my last hope, and I found that crashlytics prevented the build to complete.
Unfortunately the root cause of why it was failing with this dependency is still unclear to me.
Nevertheless, I tried to revert to the previous version of crashlytics just now and everything is fine...
So I'll check again to try to find the root cause and keep you posted if I find anything.
I created a new project to try to reproduce the issue, step by step.
My project uses multidex so I just generated some classes with a lot of method to reach dex limit.
It built without any problem so then I added one espresso and one robolectric test.
Still no problem.
I already tried to disable some of the gradle plugins we used in our app, I knew it wasn't one of them breaking the build.
So finally... I imported all of our dependencies one by one. It was blocking during the compilation process they were kind of my last hope, and I found that crashlytics prevented the build to complete.
Unfortunately the root cause of why it was failing with this dependency is still unclear to me.
Nevertheless, I tried to revert to the previous version of crashlytics just now and everything is fine...
So I'll check again to try to find the root cause and keep you posted if I find anything.
we...@gmail.com
Confirmed reverting back to Crashlytics 2.6.1 seems to resolve the issue.
be...@google.com
Can you reproduce this on a small, sample project? I tried following crashlytics install instructions on a newly created project (for Crashlytics 2.5.5) and the project still builds fine. Do you have a reliable repro steps in a project you can share? It would still be good to get to the bottom of this, even if we know it's directly related to the Crashlytics plugin/AAR.
be...@google.com
Alternatively, can you paste all of your dependencies? Maybe it's the combination of Crashlytics and something else that's problematic...
ja...@google.com
Android developers from Alaska Air are also hitting this issue.
=============
We tried running both Android Studio 2.1.x and 2.2 beta/rc with the new gradle versions. The issues we are seeing are with the new Gradle Plugin (com.android.tools.build:gradle:2.1.3) and the 2.14.1 Gradle version.
Prior to 2.1.3 and 2.14.1 combo, the “testCoverageEnabled” flag worked fine. But when we use the latest gradle versions, having the “testCoverageEnabled” flag set to true causes the build to never complete. We have let the build run for an hour with no success. It is stuck on “transformClassesWithJacocoForDebug”. We have to kill the java process for Android Studio to respond again. Once the flag is disabled, the build completes normally.
However, starting a brand new project with 2.1.3 and 2.14.1 from Android Studio wizard works fine.
==============================
Some other info:
- Changing Jacoco version didn't help
- They don't use Crashlytics
Attached are the memory dumps and thread dumps when the build got stuck.
=============
We tried running both Android Studio 2.1.x and 2.2 beta/rc with the new gradle versions. The issues we are seeing are with the new Gradle Plugin (com.android.tools.build:gradle:2.1.3) and the 2.14.1 Gradle version.
Prior to 2.1.3 and 2.14.1 combo, the “testCoverageEnabled” flag worked fine. But when we use the latest gradle versions, having the “testCoverageEnabled” flag set to true causes the build to never complete. We have let the build run for an hour with no success. It is stuck on “transformClassesWithJacocoForDebug”. We have to kill the java process for Android Studio to respond again. Once the flag is disabled, the build completes normally.
However, starting a brand new project with 2.1.3 and 2.14.1 from Android Studio wizard works fine.
==============================
Some other info:
- Changing Jacoco version didn't help
- They don't use Crashlytics
Attached are the memory dumps and thread dumps when the build got stuck.
je...@google.com
[Comment deleted]
ja...@google.com
Gradle thread dump.
be...@google.com
[Deleted User] <[Deleted User]>
I've been following this thread, as I've been having the same issue. I can confirm that turning off the testCoverageEnabled flag fixes the issue on my end. And I'm still getting coverage reports somehow. I'm guessing the 'jacoco-android' plugin I'm using is the reason why?
je...@google.com
The gradle thread dump provided seem to suggest the process is still dexing which is not the jacoco instrumentation task.
#23, can you also generate a Gradle thread dump of the gradle daemon not finishing ?
#23, can you also generate a Gradle thread dump of the gradle daemon not finishing ?
be...@google.com
Has anyone been able to reproduce it on a project that you can share with us?
If not, it would be great if someone could also attach the output of running "./gradlew :app:asembleDebug --debug", up to the point where it hangs.
If not, it would be great if someone could also attach the output of running "./gradlew :app:asembleDebug --debug", up to the point where it hangs.
rl...@gmail.com
I am also having the same issue described in this thread with Gradle 2.14.1 and build tools 2.1.3 and testCoverageEnabled set to true. Setting gradle and tools to an older version fixes the issue as well as setting testCoverageEnabled to false.
be...@google.com
Can you please send the output of running the build with --debug?
rl...@gmail.com
Unfortunately I do not think I will be able to share these details as this is not a personal project.
em...@gmail.com
I created a new, empty project and then copied over my build script from the broken project, but I haven't yet been able to replicate the problem. I'm going to iteratively add elements from the known-issue project to this new project in an attempt to create a project that demonstrates the issue which I can share with you. Thanks for your patience.
be...@google.com
@emailtonys - that would indeed be awesome if you managed to find a repro case this way. I'll keep my fingers crossed :)
My guess is that the problem has to do with JaCoCo bytecode manipulations (and the fact that we changed JaCoCo versions bundled with the android gradle plugin), so there's probably some control-flow code pattern that triggers the problem. Once we find it, it will probably still reproduce with most of other code deleted/renamed/stubbed.
My guess is that the problem has to do with JaCoCo bytecode manipulations (and the fact that we changed JaCoCo versions bundled with the android gradle plugin), so there's probably some control-flow code pattern that triggers the problem. Once we find it, it will probably still reproduce with most of other code deleted/renamed/stubbed.
em...@gmail.com
Still working on it. I should note that my project uses this:
jacoco {
toolVersion = "0.7.1.201405082137"
}
So I'm not sure if it's correct to conclude the issue is the Jacoco version.
jacoco {
toolVersion = "0.7.1.201405082137"
}
So I'm not sure if it's correct to conclude the issue is the Jacoco version.
em...@gmail.com
I've been having a lot of trouble replicating this with a simpler project. Simply copying over all my build scripts in an empty project doesn't suffice.
Our project has four modules (one base module and three "real" modules). There's a large NDK/JNI component. This makes it hard to get a minimum working reproduction for you.
I just glanced over some of the other comments on this and noticed someone talk about testCoverageEnabled. If I set that to `false` in debug {}, then the problem goes away. That's odd.
It may have gotten lost in the shuffle, but I made a comment earlier that the problem ALSO goes away if you don't have a device attached. Not really helpful in an actual dev environment, but maybe a useful clue.
Our project has four modules (one base module and three "real" modules). There's a large NDK/JNI component. This makes it hard to get a minimum working reproduction for you.
I just glanced over some of the other comments on this and noticed someone talk about testCoverageEnabled. If I set that to `false` in debug {}, then the problem goes away. That's odd.
It may have gotten lost in the shuffle, but I made a comment earlier that the problem ALSO goes away if you don't have a device attached. Not really helpful in an actual dev environment, but maybe a useful clue.
nt...@gmail.com
We have experiencing the same issue, and for us it is a BLOCKING issue in our development and release cycle, since we rely on JaCoCo to calculate the test coverage on each release.
I confirm that disabling JaCoCo with "testCoverageEnabled false" fixes the issue, but this is not acceptable for us.
Downgrading/Upgrading or changing JaCoCo version does NOT fix the issue.
Upgrading to build tools 2.2.0 does NOT fix the issue.
Our Android app is using multiple flavors and multidex enabled.
There is no workaround at the moment...
I confirm that disabling JaCoCo with "testCoverageEnabled false" fixes the issue, but this is not acceptable for us.
Downgrading/Upgrading or changing JaCoCo version does NOT fix the issue.
Upgrading to build tools 2.2.0 does NOT fix the issue.
Our Android app is using multiple flavors and multidex enabled.
There is no workaround at the moment...
aa...@gmail.com
I have been experiencing similar thing thing with gradle plugin 2.2 and gradle 3.0
If I have testCoverageEnabled true in debug build type I cant build from terminal its working from AndroidStudio though.
app is using multiple flavors, build types and is multidexed.
If I have testCoverageEnabled true in debug build type I cant build from terminal its working from AndroidStudio though.
app is using multiple flavors, build types and is multidexed.
ar...@gmail.com
I got same issue.
App includes "testCoverageEnabled true", uses android studio 2.2, gradle 2.14.1 and multiple flavors and multidex are enabled.
App includes "testCoverageEnabled true", uses android studio 2.2, gradle 2.14.1 and multiple flavors and multidex are enabled.
je...@google.com
can one of you please add --debug to your gradle invocations and attach the output.
thx
thx
xa...@gmail.com
I'v got the same problem, but setting gradle to 2.1.2 on android studio 2.2 fix the problem...
nt...@gmail.com
This issue is NOT related to Android Studio, any version.
I am running everything in terminal using the gradle wrapper, independently of Android Studio.
Attached the last part of the output.
Basically, it stays stuck with cpu @ 100% and eating memory with this output:
[DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
[DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
> Building 97% > :app:transformClassesWithDexForStoreGoogleDebug
and then it keeps repeating the locking part
I hope it helps
I am running everything in terminal using the gradle wrapper, independently of Android Studio.
Attached the last part of the output.
Basically, it stays stuck with cpu @ 100% and eating memory with this output:
[DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
[DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
> Building 97% > :app:transformClassesWithDexForStoreGoogleDebug
and then it keeps repeating the locking part
I hope it helps
be...@google.com
[Comment deleted]
be...@google.com
As mentioned in #30: it seems the problem is triggered by JaCoCo running over code with a specific "shape" and then dexing JaCoCo's output. It's very hard to guess what the problem is without a repro project.
Since we can't get access to any of the projects that trigger this behavior, I can only ask one of you to try to get a minimal repro case: keep deleting code from your project as long as the problem persists. Then rename everything in what's left and share with us. I honestly don't know how else we can move forward here.
Since we can't get access to any of the projects that trigger this behavior, I can only ask one of you to try to get a minimal repro case: keep deleting code from your project as long as the problem persists. Then rename everything in what's left and share with us. I honestly don't know how else we can move forward here.
to...@gmail.com
Are you able to provide some sort of privacy assurance, or is that just impossible in this kind of situation?
da...@intuit.com
I am seeing the same issue as message #38 above. If I disable test coverage, it goes away. I am using android gradle plugin 2.2.0, and tried with both gradle 2.14.1 and 2.3.1. What's curious is that my project has a few subprojects, and this does not occur on all of them, but I can't for the life of me figure the difference between ones that fail in this way and ones that succeed. Also of note, my project is multidex.
vc...@gmail.com
I am experiencing the exact same problem. I removed the testCoverageEnabled line in my build.gradle and everything started to work fine.
da...@intuit.com
Here's some debug output. In this scenario, I'm just trying to run connectedAndroidTest for a single subproject connected to my full project. If I disable code coverage it will build, but if I enable it it will stall out. Output ends when I abort with ctrl-c.
ph...@gmail.com
Hi,
I'm experiencing the same issue in our project,
compile with gradle 2.14.1 and jacoco,
our project stuck in transformClassesWithDexForDebug with assembleDebug, and testCoverageEnable true,
after a long time search I found removing these code could resolve the problem,
==========================================================================
for(int i = 0; i < mResult.size() ;i++){
SubjectListInfo.SubjectData indexData12 = (SubjectListInfo.SubjectData)mResult.get(i);
if(indexData12.mArticalId.equals(indexData.mArticalId)){ <-
contains = true; <-
break; <-
} <-
}
==========================================================================
yet the true cause of this issue remain unknown,
wonder if this would help.
I'm experiencing the same issue in our project,
compile with gradle 2.14.1 and jacoco,
our project stuck in transformClassesWithDexForDebug with assembleDebug, and testCoverageEnable true,
after a long time search I found removing these code could resolve the problem,
==========================================================================
for(int i = 0; i < mResult.size() ;i++){
SubjectListInfo.SubjectData indexData12 = (SubjectListInfo.SubjectData)mResult.get(i);
if(indexData12.mArticalId.equals(indexData.mArticalId)){ <-
contains = true; <-
break; <-
} <-
}
==========================================================================
yet the true cause of this issue remain unknown,
wonder if this would help.
wa...@gmail.com
I see it “Waiting to acquire shared lock on daemon addresses registry” and “Releasing lock on daemon addresses registry” over and over again.
da...@intuit.com
Android team:
It's been 2 months since Android Plugin for Gradle 2.1.3 was released – you've since moved on to 2.2 – and yet all of us with this issue are still stuck on v2.1.2 or earlier. Can we get some resolution to this problem?
It's been 2 months since Android Plugin for Gradle 2.1.3 was released – you've since moved on to 2.2 – and yet all of us with this issue are still stuck on v2.1.2 or earlier. Can we get some resolution to this problem?
be...@google.com
While we're looking into this (still cannot reproduce for now), is this related to the version of our Gradle plugin alone, or build tools as well?
da...@intuit.com
Though we're still using Gradle Android plugin 2.1.3 and Gradle 2.10, we've had no trouble upgrading build tools to the latest version – we're using 24.0.3 currently. This trouble only occurs if we upgrade Gradle Android plugin to 2.1.3 or 2.2 and Gradle to 2.14.1 or 3.1 (I tried both.)
I have not tried upgrading gradle without upgrading the gradle android plugin, as I was under the impression that plugin 2.1.3 needed gradle 2.10.
Thanks!
I have not tried upgrading gradle without upgrading the gradle android plugin, as I was under the impression that plugin 2.1.3 needed gradle 2.10.
Thanks!
[Deleted User] <[Deleted User]>
same issue here.
Multidex, testCoverageEnable true
gradle 3.1
android gradle plugin 2.2.1
Multidex, testCoverageEnable true
gradle 3.1
android gradle plugin 2.2.1
be...@google.com
OK, we were able to reproduce it on https://github.com/google/ExoPlayer.git . For the record, I attach the class file that tricks the dx compiler.
ak...@gmail.com
I disabled testcoverage and it started to work.
m4...@gmail.com
Same here, fails as soon as we upgrade to
com.android.tools.build:gradle:2.1.3
So for now we are stuck on 2.1.2 and therefore gradle < 2.14 (we use 2.11)
com.android.tools.build:gradle:2.1.3
So for now we are stuck on 2.1.2 and therefore gradle < 2.14 (we use 2.11)
cm...@google.com
Fix is submitted in dx and dex-in-process fix is in review.
ag/I4769cfa51432765905fc486e12207f94da174b6d
ag/I4769cfa51432765905fc486e12207f94da174b6d
ja...@gmail.com
so what's the solution to this ? can anyone give a explainnation to this ?
da...@intuit.com
Jason: Someone at google has submitted a fix. Hopefully this fix will be integrated into the next release.
members: Can we get an update on this? Timeline?
Thanks!
members: Can we get an update on this? Timeline?
Thanks!
[Deleted User] <[Deleted User]>
As of today, this is still occurring for me in the latest nightly gradle build using distributionUrl=https\://services.gradle.org/distributions-snapshots/gradle-3.3-20161119000048+0000-bin.zip . Any ETA on when this review will get checked in ?
ji...@gmail.com
Any workaround or way to debug this in order to find what is causing this ? Until the fix found available.
cm...@google.com
The workaround is to disable test coverage for the moment.
ja...@gmail.com
Version 2.2.3 was just released. Can we expect 2.3 soon?
da...@intuit.com
@jaredsburrows I think changes to Android Studio are completely orthogonal to this problem. AFAIK this problem will require a release to the Android Plugin for Gradle <https://developer.android.com/studio/releases/gradle-plugin.html >
Project folks, is that right? Or is it in some other package this is happening?
Project folks, is that right? Or is it in some other package this is happening?
ja...@google.com
Blocked on internal bug:
ja...@gmail.com
@david_pisoni I don't use Android Studio. I as asking about the Android plugin release.
@james Thanks for answering.
@james Thanks for answering.
cm...@google.com
Fix in Dx turns out to break other things, so it had to be reverted.
I'm actively looking for other ways to work around this in the short term.
For the record, this is an issue with the dx tool when applied to code that is generated by jacoco instrumentation, and was a latent issue caused by the jacoco version being bumped from 2.1.2 -> 2.1.3.
I'm actively looking for other ways to work around this in the short term.
For the record, this is an issue with the dx tool when applied to code that is generated by jacoco instrumentation, and was a latent issue caused by the jacoco version being bumped from 2.1.2 -> 2.1.3.
cm...@google.com
A workaround is submitted in master: Downgrade jacoco to 0.7.4.201502262128
Before it is released you can perhaps use a resolution strategy in gradle to force that version, which should work round the issue.
Before it is released you can perhaps use a resolution strategy in gradle to force that version, which should work round the issue.
ja...@google.com
Change-Id: Ic17c0af8539193f805c85dee9c1ff7c0c2f8e79c
ja...@gmail.com
[Comment deleted]
tu...@gmail.com
Hi, any solution for this issue?
I'm using gradle 2.14.1,
- multidexEnabled true,
- testCoverageEnable true
- android gradle plugin 2.1.2
And task transformClassesWithDexForDebug always stuck :(
Please help.
I'm using gradle 2.14.1,
- multidexEnabled true,
- testCoverageEnable true
- android gradle plugin 2.1.2
And task transformClassesWithDexForDebug always stuck :(
Please help.
ja...@gmail.com
@70 Here is the solution suggested by @67:
androidJacocoAgent "org.jacoco:org.jacoco.agent:0.7.4.201502262128"
androidJacocoAnt "org.jacoco:org.jacoco.ant:0.7.4.201502262128"
jacocoAgent "org.jacoco:org.jacoco.agent:0.7.4.201502262128"
jacocoAnt "org.jacoco:org.jacoco.agent:0.7.4.201502262128"
Downgrading is not a solution. This really needs to be addressed in 2.3.
androidJacocoAgent "org.jacoco:org.jacoco.agent:0.7.4.201502262128"
androidJacocoAnt "org.jacoco:org.jacoco.ant:0.7.4.201502262128"
jacocoAgent "org.jacoco:org.jacoco.agent:0.7.4.201502262128"
jacocoAnt "org.jacoco:org.jacoco.agent:0.7.4.201502262128"
Downgrading is not a solution. This really needs to be addressed in 2.3.
cm...@google.com
Due to dependency resolution that won't actually downgrade jacoco, you'd need to force the version using a resolution strategy.
e.g.
buildscript {
configurations.all {
resolutionStrategy {
force 'org.jacoco:org.jacoco.report:0.7.4.201502262128'
force 'org.jacoco:org.jacoco.core:0.7.4.201502262128'
}
}
}
e.g.
buildscript {
configurations.all {
resolutionStrategy {
force 'org.jacoco:org.jacoco.report:0.7.4.201502262128'
force 'org.jacoco:org.jacoco.core:0.7.4.201502262128'
}
}
}
nt...@gmail.com
@72 this workaround works for me. Thanks!
[Deleted User] <[Deleted User]>
I had this issue, but it started spontaneously during development. I tracked the code change which caused this issue for me, and it turned out to be caused by two nested for loops, inside a do while loop in production code.
When I commented out either of the two for loops, the problem went away. I changed the for loops to for each loops, and the problem went away.
Disabling testCoverageEnabled also worked around it for me.
When I commented out either of the two for loops, the problem went away. I changed the for loops to for each loops, and the problem went away.
Disabling testCoverageEnabled also worked around it for me.
mu...@gmail.com
I was able to reproduce this issue, finding something similar to @74. Here is a simple code which should reproduce the behaviour.
public class Bug {
public int size = 0;
public Bug(List<Entry> entries, int valueCount) {
for (Entry entry : entries) {
if (entry.flag) {
for (int t = 0; t < valueCount; t++) {
size += entry.length;
}
} else {
for (int t = 0; t < valueCount; t++) {
size -= entry.length;
}
}
}
}
public final class Entry {
private final int length;
private final boolean flag;
public Entry(boolean flag, int length) {
this.length = length;
this.flag = flag;
}
}
}
The bug does not appear when all loops are for each loops, or when the code is made any simpler (removing a loop, or removing if else).
public class Bug {
public int size = 0;
public Bug(List<Entry> entries, int valueCount) {
for (Entry entry : entries) {
if (entry.flag) {
for (int t = 0; t < valueCount; t++) {
size += entry.length;
}
} else {
for (int t = 0; t < valueCount; t++) {
size -= entry.length;
}
}
}
}
public final class Entry {
private final int length;
private final boolean flag;
public Entry(boolean flag, int length) {
this.length = length;
this.flag = flag;
}
}
}
The bug does not appear when all loops are for each loops, or when the code is made any simpler (removing a loop, or removing if else).
[Deleted User] <[Deleted User]>
I am seeing the same problematic behavior in Android Studio 2.3 Beta 3 with `testCoverageEnabled = true`. It causes the build to never complete and to get stuck endlessly. Setting that flag to false solves this issue.
em...@gmail.com
Is there a chance we might see a solution to this issue this year? I just had to deal with upgrading to 'stable' AS 2.3, which tried very hard to force me to 'upgrade' to the latest, still-broken build tools. Disabling test coverage is not a solution. Please please please fix this problem.
dp...@gmail.com
[Comment deleted]
dp...@gmail.com
[Comment deleted]
da...@intuit.com
Hear hear! This issue is marked as "Priority-Critical", why wasn't it fixed for the latest release?
[Deleted User] <[Deleted User]>
Same problem using AS 2.3 build-tools 2.3.0.
xi...@gmail.com
when set testCoverageEnabled = true，build blocked...Attach part jenkins build log file below.Its block at last step, after build 35mins, i stopped it.
Finally i found when i checkout my code to previous version,its could build success,then i checkout to which version start cannot build,then found when i upgrade grade from 2.1.0 to 2.2.0, it begin to cannot build success while i set testCoverageEnabled = true.so i user gradle 2.1.0 it run...
The weird thing is that when i create a simple project, it cannot happen even i set gradle version to 2.2.0 or 2.2.2
Finally i found when i checkout my code to previous version,its could build success,then i checkout to which version start cannot build,then found when i upgrade grade from 2.1.0 to 2.2.0, it begin to cannot build success while i set testCoverageEnabled = true.so i user gradle 2.1.0 it run...
The weird thing is that when i create a simple project, it cannot happen even i set gradle version to 2.2.0 or 2.2.2
[Deleted User] <[Deleted User]>
@73 can you share your configuration:
- gradle version
- gradle build tool version
that work with @72 workaround
My project still stuck transformClassesWithDexFor task even using the workaround
- gradle version
- gradle build tool version
that work with @72 workaround
My project still stuck transformClassesWithDexFor task even using the workaround
tu...@gmail.com
@73: I used @72 workaround in build.gradle file and
- I can build project successfully.
- But the exec files(.ec) is formatted in jacoco version 0.7.4 and if you're using gradle 2.14.1 we can't create final report from these exec files
-Reason: The exec file version has been updated and is not compatible with previous versions from jacoco 0.7.5 up, as this link:http://www.jacoco.org/jacoco/trunk/doc/changes.html
- Anyone has other solutions?
- I can build project successfully.
- But the exec files(.ec) is formatted in jacoco version 0.7.4 and if you're using gradle 2.14.1 we can't create final report from these exec files
-Reason: The exec file version has been updated and is not compatible with previous versions from jacoco 0.7.5 up, as this link:
- Anyone has other solutions?
rg...@gmail.com
We have set this in our build.gradle but we are facing a related issue:
buildscript {
configurations.all {
resolutionStrategy {
force 'org.jacoco:org.jacoco.report:0.7.4.201502262128'
force 'org.jacoco:org.jacoco.core:0.7.4.201502262128'
}
}
}
We have a mix of unit tests and connected tests. We run them in succession so first we get .ec code coverage file when we run connected tests and then we get .exec code coverage file when we unit tests. Then we try to upload the code coverage reports to Sonar and it gives this error:
WARN - You are not using the latest JaCoCo binary format version, please consider upgrading to latest JaCoCo version.
ERROR - Execution failed for task 'sonarqube'.
> Incompatible execution data for class xyz with id 12345
Looks like we need to upgrade the jacoco version. If we try to update it brings us back to square one - the build hanging issue. Looks like we are in for a catch 22.
Suggestions?
buildscript {
configurations.all {
resolutionStrategy {
force 'org.jacoco:org.jacoco.report:0.7.4.201502262128'
force 'org.jacoco:org.jacoco.core:0.7.4.201502262128'
}
}
}
We have a mix of unit tests and connected tests. We run them in succession so first we get .ec code coverage file when we run connected tests and then we get .exec code coverage file when we unit tests. Then we try to upload the code coverage reports to Sonar and it gives this error:
WARN - You are not using the latest JaCoCo binary format version, please consider upgrading to latest JaCoCo version.
ERROR - Execution failed for task 'sonarqube'.
> Incompatible execution data for class xyz with id 12345
Looks like we need to upgrade the jacoco version. If we try to update it brings us back to square one - the build hanging issue. Looks like we are in for a catch 22.
Suggestions?
dp...@gmail.com
Can we get an update on this issue? Is it still slated to be fixed at some point?
cy...@gmail.com
I encountered this issue too. Any update on this issue? This issue is "Priority-Critical". Why do no one in google care this?
[Deleted User] <[Deleted User]>
da...@intuit.com
Definitely not the only cause... my project doesn't use LruCache and I see the same problem.
em...@gmail.com
I see there's another new AS release, but I won't even try to use it -- I'm confident you'll try to break Gradle 2.14 again and the old (but functional!) build tools again.
Guys, I'd really love to upgrade to the latest and greatest and get all the wonderful speed boosts, but testing is a first-class citizen around here. What's the eta on fixing this problem?
Guys, I'd really love to upgrade to the latest and greatest and get all the wonderful speed boosts, but testing is a first-class citizen around here. What's the eta on fixing this problem?
cm...@google.com
We are working on a comprehensive fix, but it will take a while, as it fundamentally changes the way way dexing is done.
#83 - if you are using our inbuilt jacoco report task, that should just work. If you are using gradle's in built jacoco task, you should be able to set the version to match.
#83 - if you are using our inbuilt jacoco report task, that should just work. If you are using gradle's in built jacoco task, you should be able to set the version to match.
em...@gmail.com
Thanks for the note #90. I think we were beginning to feel a bit abandoned on this one. Glad to know it's in progress.
IS there an estimate on this, though?
IS there an estimate on this, though?
[Deleted User] <[Deleted User]>
I'm facing the same issue when trying to run my project with the following configs - android gradle 2.2.2/2.2.3 and gradle 2.14.1, and android gradle 2.3.0/2.3.1 with gradle 3.3 despite of downgrading jacoco to 0.7.4+, I want to make use of build caching to speed things up with my build, any help would be much appreciated. I've practically tried a lot of combinations with android plugin and gradle version but to no luck.
[Deleted User] <[Deleted User]>
I can confirm the problem still reproduces with Gradle 3.3, Android Plugin Version 2.3.0. Disabling test coverage fixes the issue, but it is not a solution.
[Deleted User] <[Deleted User]>
Are their any updates on the issue ? I am currently facing the same behavior. Gradle plugin 3.3 and build tools 2.3.1. Jacoco versionis 0.7.9.
cm...@google.com
As stated before, workaround is to use jacoco 0.7.4.201502262128
e.g. e.g.
buildscript {
configurations.all {
resolutionStrategy {
force 'org.jacoco:org.jacoco.report:0.7.4.201502262128'
force 'org.jacoco:org.jacoco.core:0.7.4.201502262128'
}
}
}
e.g. e.g.
buildscript {
configurations.all {
resolutionStrategy {
force 'org.jacoco:org.jacoco.report:0.7.4.201502262128'
force 'org.jacoco:org.jacoco.core:0.7.4.201502262128'
}
}
}
aa...@gmail.com
but adding the above jacoco res strategy, I can't generate unit test
coverage report :(
On Tue, May 16, 2017 at 9:36 PM, <buganizer-system@google.com> wrote:
coverage report :(
On Tue, May 16, 2017 at 9:36 PM, <buganizer-system@google.com> wrote:
--
*Regards,*
*Aamir Abro*
to...@gmail.com
That workaround isn't working for us. It _almost_ seems to work, insofar as the problem with endless dexing has gone away, but we have issues with running our tests. Here is a gist with the stacktrace: https://gist.github.com/autonomousapps/4142bbb5af18c5515273b28adc6e3516
This might be related to this issue:https://issuetracker.google.com/issues/37136626
Our current configuration while testing this workaround:
* Support version 25.0.0 (we were having issues with 25.0.3; bug report filed)
* Gradle Build tools 2.3.2
* Build tools 25.0.3
* SDK target 25
* Gradle 3.3
And, as I said, the workaround:
buildscript {
repositories { ... }
dependencies { ... }
configurations.all {
resolutionStrategy {
force 'org.jacoco:org.jacoco.report:0.7.4.201502262128'
force 'org.jacoco:org.jacoco.core:0.7.4.201502262128'
}
}
}
We also have this, elsewhere in our build script:
jacoco {
// Workaround for error `Incompatible version 1006`
toolVersion = '0.7.4.201502262128' // '0.7.7.201606060606'
}
This might be related to this issue:
Our current configuration while testing this workaround:
* Support version 25.0.0 (we were having issues with 25.0.3; bug report filed)
* Gradle Build tools 2.3.2
* Build tools 25.0.3
* SDK target 25
* Gradle 3.3
And, as I said, the workaround:
buildscript {
repositories { ... }
dependencies { ... }
configurations.all {
resolutionStrategy {
force 'org.jacoco:org.jacoco.report:0.7.4.201502262128'
force 'org.jacoco:org.jacoco.core:0.7.4.201502262128'
}
}
}
We also have this, elsewhere in our build script:
jacoco {
// Workaround for error `Incompatible version 1006`
toolVersion = '0.7.4.201502262128' // '0.7.7.201606060606'
}
cm...@google.com
em...@gmail.com
To update my last comment, I was able to get it to work by making a small change to our jenkinsfile which generates a build report. We had been looking for the test report here:
app/build/reports/tests/flavorDebug/
but it was moved to here:
app/build/reports/tests/testFlavorDebugUnitTest
By changing from the former to the latter, the 'workaround' from above now works for us.
app/build/reports/tests/flavorDebug/
but it was moved to here:
app/build/reports/tests/testFlavorDebugUnitTest
By changing from the former to the latter, the 'workaround' from above now works for us.
vi...@gmail.com
We reproduced it in a sample app and looks like the problem is with the dexMethodCount.
When we add multiple libraries in the sample project where it reaches to ~80000 dexMethodCount, it started failing for us. We made it working by setting javaMaxHeapSize as 2g. But for our application which is pretty huge around 141872 dexMethodCount, it is not working.
Just FYI, we had also tried resolutionStrategy solution mentioned above, it did not work for us. Mulitidexing was enabled in sample project also.
When we add multiple libraries in the sample project where it reaches to ~80000 dexMethodCount, it started failing for us. We made it working by setting javaMaxHeapSize as 2g. But for our application which is pretty huge around 141872 dexMethodCount, it is not working.
Just FYI, we had also tried resolutionStrategy solution mentioned above, it did not work for us. Mulitidexing was enabled in sample project also.
da...@intuit.com
Still broken with gradle 3.5.1 / build tools 26.0.0 / android gradle plugin 2.3.3.
This issue is rapidly approaching the 1-year mark...
This issue is rapidly approaching the 1-year mark...
li...@gmail.com
also encounter this issue
Gradle version:3.3
AS version:2.3.3
issue occur when testCoverageEnabled is true, jacoco version 0.7.9
plz solve this issue as soon as possible, thanks
Gradle version:3.3
AS version:2.3.3
issue occur when testCoverageEnabled is true, jacoco version 0.7.9
plz solve this issue as soon as possible, thanks
cm...@google.com
This issue should be addressed by switching to using D8.
Set android.enableD8=true in your gradle.properties file (not build.gradle)
https://android-developers.googleblog.com/2017/08/next-generation-dex-compiler-now-in.html
The workaround of using the last jacoco version that didn't cause this issue is also fine.
#99, please file a new issue with a reproducible test case, we can always de-duplicate but discussing on an existing bug just makes the issue more difficult to follow
Set android.enableD8=true in your gradle.properties file (not build.gradle)
The workaround of using the last jacoco version that didn't cause this issue is also fine.
#99, please file a new issue with a reproducible test case, we can always de-duplicate but discussing on an existing bug just makes the issue more difficult to follow
ne...@gmail.com
#102
Strange enough I have this issue with D8 enabled, so enabling D8 does not work for me (Android Studio 3.1 build tools 3.1.0). When I disable D8 and use DX it works fine.
Strange enough I have this issue with D8 enabled, so enabling D8 does not work for me (Android Studio 3.1 build tools 3.1.0). When I disable D8 and use DX it works fine.
ga...@google.com
Re #103:
Just to double check, the build does not finish? Can you please upload a stacktrace using jstack?
Just to double check, the build does not finish? Can you please upload a stacktrace using jstack?
ne...@gmail.com
I will try to generate a jstack stacktrace. Just to add some details: this is on a windows 10 machine for a project that was previously working with Android Studio 3.0 and the old DX compiler.
ne...@gmail.com
I've added a dump, I'm not sure what exactly hangs or goes wrong.
ga...@google.com
Re #106:
I've filledhttps://issuetracker.google.com/77182828 to track this issue. Let's continue discussion there please.
I've filled
ga...@google.com
Our new dex compiler, D8, does not have this issue, and it is able to process Jacoco-instrumented bytecode correctly. It has been enabled by default from Android Studio 3.2. In case you encounter any issues with D8, please file a bug at https://issuetracker.google.com/issues/new?component=317603&template=1018721 . Thanks you all for helping debug this issue!
Description
Android Plugin Version: 2.1.3
SDK Version: 25.1.7
Module Compile Sdk Version: 23
Module Build Tools Version: 23.0.3
I first attempted help with this issue on the Gradle forums:
A Gradle core dev said that it looks like an issue with the Android tool, and suggested I come here.
THE ISSUE:
When I attempt to install the app (either via the green arrow in the IDE, or from the command line), it hangs indefinitely at the task `:app:transformClassesWithDexForDebug`. I acquired a stack trace using jstack, which produced the output I've attached and pasted here on hastebin (too large to paste):
The critical part might be here, which I'm pasting directly:
```
tonyrobalik@Tonys-MacBook-Pro:/workspace/project$
jps
11122 GradleDaemon
468
11190 Jps
11116 GradleWrapperMain
tonyrobalik@Tonys-MacBook-Pro:/workspace/project$
jstack 11122
2016-08-22 09:24:08
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode):
"Attach Listener" #478 daemon prio=9 os_prio=31 tid=0x00007ff0b43df000 nid=0xb353 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"pool-104-thread-2" #430 prio=5 os_prio=31 tid=0x00007ff0b4610000 nid=0xcf37 runnable [0x000070000380e000]
java.lang.Thread.State: RUNNABLE
at com.android.dx.rop.code.LocalVariableExtractor.doit(LocalVariableExtractor.java:79)
at com.android.dx.rop.code.LocalVariableExtractor.extract(LocalVariableExtractor.java:47)
at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:319)
at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:141)
at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:95)
at com.android.dx.command.dexer.Main.translateClass(Main.java:779)
at com.android.dx.command.dexer.Main.access$2800(Main.java:87)
at com.android.dx.command.dexer.Main$ClassTranslatorTask.call(Main.java:1829)
at com.android.dx.command.dexer.Main$ClassTranslatorTask.call(Main.java:1814)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
```