Dex failure in canary studio beta 2 [37080526]

Fixed

Bug

[AOSP] Version-Studio-2.0

[AOSP] NotEnoughInformation

[AOSP] Version-Studio-2.2

Migrated-Tools-Instant Run

NeedsInfo

[AOSP] FutureRelease

Migrated-Tools-Gradle

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Feb 5, 2016 02:13AM

With canary studio beta 2 and gradle plugin beta2 on a project with databinding I am getting a dex error when building.

100% reproducible

If I use gradle plugin alpha9 I am able to build.

setting incremental to true, false or unspecified has no effect.

minSdk 21
target/compile 23

logs:

AGPBI: {"kind":"error","text":"Error converting bytecode to dex:\nCause: java.lang.RuntimeException: Exception parsing classes","sources":[{}],"original":"UNEXPECTED TOP-LEVEL EXCEPTION:\njava.lang.RuntimeException: Exception parsing classes\n\tat com.android.dx.command.dexer.Main.processClass(Main.java:752)\n\tat com.android.dx.command.dexer.Main.processFileBytes(Main.java:718)\n\tat com.android.dx.command.dexer.Main.access$1200(Main.java:85)\n\tat com.android.dx.command.dexer.Main$FileBytesConsumer.processFileBytes(Main.java:1645)\n\tat com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:170)\n\tat com.android.dx.cf.direct.ClassPathOpener.processDirectory(ClassPathOpener.java:229)\n\tat com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:158)\n\tat com.android.dx.cf.direct.ClassPathOpener.processDirectory(ClassPathOpener.java:229)\n\tat com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:158)\n\tat com.android.dx.cf.direct.ClassPathOpener.processDirectory(ClassPathOpener.java:229)\n\tat com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:158)\n\tat com.android.dx.cf.direct.ClassPathOpener.processDirectory(ClassPathOpener.java:229)\n\tat com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:158)\n\tat com.android.dx.cf.direct.ClassPathOpener.processDirectory(ClassPathOpener.java:229)\n\tat com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:158)\n\tat com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)\n\tat com.android.dx.command.dexer.Main.processOne(Main.java:672)\n\tat com.android.dx.command.dexer.Main.processAllFiles(Main.java:574)\n\tat com.android.dx.command.dexer.Main.runMultiDex(Main.java:366)\n\tat com.android.dx.command.dexer.Main.run(Main.java:275)\n\tat com.android.dx.command.dexer.Main.main(Main.java:245)\n\tat com.android.dx.command.Main.main(Main.java:106)\n","tool":"Dex"}

xxxprojectxxx:transformClassesWithDexForDevDebug FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':xxxprojectxxx:transformClassesWithDexForDevDebug'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_71.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Comments

vs...@google.com <vs...@google.com> Feb 5, 2016 02:19AM

Assigned to je...@google.com.

je...@google.com <je...@google.com> Feb 5, 2016 04:24PM

Reassigned to cm...@google.com.

yb...@google.com <yb...@google.com> #2Feb 5, 2016 06:04PM

We use build flavours heavily with a lot of common code. The refactoring support in AS is really good but it continually catches us out when it doesn't work across all flavours in a project. It's a big gap for serious product development.

[Deleted User] <[Deleted User]> #3Feb 5, 2016 06:14PM

We at my company need this same feature. We have a lot of white labels and need refactor the same class across flavours. :(

je...@google.com <je...@google.com> #4Feb 5, 2016 06:21PM

I need this feature too...

[Deleted User] <[Deleted User]> #5Feb 5, 2016 07:07PM

+1, I need this very badly

je...@google.com <je...@google.com> #6Feb 5, 2016 07:36PM

+1 My company also need this feature.

cm...@google.com <cm...@google.com> #7Feb 5, 2016 07:49PM

Can we atleast know the status of the issue please? Will it be fixed or is it in low priority. It's been 4 years.

[Deleted User] <[Deleted User]> #8Feb 5, 2016 08:43PM

We are currently investigating possibly solutions.

je...@google.com <je...@google.com> #9Feb 5, 2016 08:47PM

+1 This will exclude a lot of unnecessary work. In my work I have 25 flavours. :(

[Deleted User] <[Deleted User]> #10Feb 5, 2016 08:49PM

+1 .. we need it as well...

je...@google.com <je...@google.com> #11Feb 5, 2016 08:56PM

Any update on this?

[Deleted User] <[Deleted User]> #12Feb 5, 2016 09:10PM

We also need this feature...please...

gradle_failure_redacted.txt

9 KB

View

Download

cm...@google.com <cm...@google.com> #13Feb 5, 2016 10:26PM

I would like to vote for this feature as well.

[Deleted User] <[Deleted User]> #14Feb 5, 2016 10:39PM

cm...@google.com <cm...@google.com> #15Feb 9, 2016 08:02PM

Status: New

Build flavor source code is useless until this is fixed.

[Deleted User] <[Deleted User]> #16Feb 9, 2016 10:55PM

cm...@google.com <cm...@google.com> #17Feb 9, 2016 11:32PM

[Deleted User] <[Deleted User]> #18Feb 10, 2016 12:14AM

+1 "Build flavor source code is useless until this is fixed." - agree

be...@google.com <be...@google.com> #19Mar 3, 2016 04:20PM

[Deleted User] <[Deleted User]> #20Mar 3, 2016 11:24PM

My team are heavy users of Android Flavours and the IDE remaining semantically aware of all flavours besides the currently 'focused' one, for refactoring and searching purposes, would be a major productivity boost.
Indeed, the current state almost feels like flavours are only partially supported in the IDE.

cm...@google.com <cm...@google.com> #21Mar 4, 2016 12:54AM

This is the joy of case preserving but case insensitive file systems...

I think I have enough to reproduce this :)

be...@google.com <be...@google.com> #22Mar 4, 2016 10:12AM

To give you a bit more context: currently we don't handle libraries that use a.class and A.class correctly on OS X (since we unpack the jars for processing). The default ProGuard flags for android projects include -dontusemixedcaseclassnames which prevents this from happening in AAR files built with Gradle.

If you don't have sources for the AAR but know the "entry points", you may want to re-ProGuard classes.jar with the flag mentioned and appropriate -keep rules.

cm...@google.com <cm...@google.com> #23Mar 4, 2016 08:00PM

Also, if the prebuilt aar was built with Android Gradle Plugin before 1.5 even with -dontusemixedcaseclassnames it could still generate a class called 'r'.

For libraries obfuscated with 1.5 we keep the R class with ProGuard and also pass -dontusemixedcaseclassnames which solves the issue. (the R class is removed in the jar phase)

[Deleted User] <[Deleted User]> #24May 25, 2016 01:27PM

I do not have source code of the library and I am facing the same issues. Please suggest me with what can be done to resolve the issue.

Is it going to be fixed in future releases?

[Deleted User] <[Deleted User]> #25May 25, 2016 04:13PM

it's been a few months since I reported it, I'm still trying to work with my library vendor to get a compatible library from them, but it's out of my control. Is this issue being recognized as a bug that's going to be resolved?

cm...@google.com <cm...@google.com> #26Aug 11, 2016 12:29AM

Marked as fixed, reassigned to cm...@google.com.

This won't be fixed in 2.2, but in the subsequent release we will treat AARs added to configurations as remote and you won't see this issue.

As a workaround you can use the aar in a repository instead, which should make it appear remote:
repositories { flatDir { dirs 'libs' } }
dependencies { compile(name:'filename', ext:'aar'}}
or use a case-sensitive disk image.

[Deleted User] <[Deleted User]> #27Aug 11, 2016 12:36AM

Thanks for the update

[Deleted User] <[Deleted User]> #28Aug 11, 2016 06:54PM

Your workaround did work, our team is now able to use Instant Run - thanks!