aar file contains android-support-v4.jar, causing problems

[Traun Leyden]

I'm creating a library using this build.gradle:

...

repositories {

    mavenCentral()

}

dependencies {

    compile files('libs/android-support-v4.jar')

    instrumentTestCompile 'commons-io:commons-io:2.0.1'

    compile 'org.codehaus.jackson:jackson-core-asl:1.9.2'

    compile 'org.codehaus.jackson:jackson-mapper-asl:1.9.2'

}

uploadArchives {

    repositories {

        mavenDeployer {

            repository(url: uri("../testrepo"))

            ..

        }

    }

}

..

and then I'm running "./gradlew :CBLite:uploadArchives", which causes an .aar to be generated in the local testrepo directory.  When I unzip the .aar, I can see that it contains lib/ android-support-v4.jar.

The problems start when I try to use the generated .aar as a dependency in another project.  Here's the build.gradle from the project which consumes this dependency:

...

repositories {

    mavenCentral()

    maven {

        url "file:///../couchbase-lite-android/CouchbaseLiteProject/testrepo"

    }

}

dependencies {

    compile files('libs/android-support-v4.jar')

    compile 'com.couchbase.cblite:CBLite:1.0'

}

...

when I try to build the project with "./gradlew assemble", I get this error:

:HelloCBLite:dexDebug

UNEXPECTED TOP-LEVEL EXCEPTION:

java.lang.IllegalArgumentException: already added: Landroid/support/v4/app/ActivityCompatHoneycomb;

at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)

at com.android.dx.dex.file.DexFile.add(DexFile.java:163)

at com.android.dx.command.dexer.Main.processClass(Main.java:490)

at com.android.dx.command.dexer.Main.processFileBytes(Main.java:459)

at com.android.dx.command.dexer.Main.access$400(Main.java:67)

at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:398)

at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)

at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)

at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)

at com.android.dx.command.dexer.Main.processOne(Main.java:422)

at com.android.dx.command.dexer.Main.processAllFiles(Main.java:333)

at com.android.dx.command.dexer.Main.run(Main.java:209)

at com.android.dx.command.dexer.Main.main(Main.java:174)

at com.android.dx.command.Main.main(Main.java:91)

1 error; aborting

:HelloCBLite:dexDebug FAILED

FAILURE: Build failed with an exception.

* What went wrong:

Execution failed for task ':HelloCBLite:dexDebug'.

> Running /Applications/Android Studio.app/sdk/build-tools/android-4.2.2/dx failed. See output

* Try:

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

 

From the error, it looks like it's trying to add in classes from android-support-v4.jar into the classes.dex, which have already been added since they were included in the dependency .aar.  

Is the .aar of a library supposed to contain android-support-v4.jar?  

[Xavier Ducrohet]

This is expected when referencing local jars from library projects. There's no way around it, we need to include it in aar.

I'm working right now to have those in a repository so that you can reference artifact instead which will allow Gradle to resolve the dependencies correctly when building an app using different library projects that all depends on support-v4 or other support libs.

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Traun Leyden]

So I guess the most obvious workaround is that any projects consuming this .aar should simply remove "dependencies { compile files('libs/android-support-v4.jar') }"?

I tried it and it fixed the problem.  Hopefully there'll be no side effects.

[Alberto Alonso Ruibal]

Traun, provisionally you can also install android-support-v4.jar to your local maven repo with:

mvn install:install-file -Dfile=android-support-v4.jar -DgroupId=com.google  -DartifactId=android-support-v4 -Dversion=0.1 -Dpackaging=jar

and then reference it from your projects build.gradle:

repositories {

    mavenLocal()

    mavenCentral()

}

dependencies {

    compile 'com.google:android-support-v4:0.1'

//...

[Traun Leyden]

Thanks!

[Xavier Ducrohet]

provided is not the solution.

Right now you need to make sure you have a single library project that contains support.jar and have all other library project depend on it. This will ensure only one support.jar is used.

Very soon now we're going to release a repository with the support library. This means you'll be able to properly reference it as an artifact and not as a local jar file, which will make Gradle's dependency resolution able to remove duplicates.

On Sun, May 26, 2013 at 10:32 AM, Rainer Burgstaller <rbu...@gmail.com> wrote:

Alberto, I tried this but still dont have any success. I have 2 libraries which each depend on support-v4 as well as the main app that relies on it. I get the error message

UNEXPECTED TOP-LEVEL EXCEPTION:

java.lang.IllegalArgumentException: already added: Landroid/support/v4/app/ActivityCompatHoneycomb;

at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)

at com.android.dx.dex.file.DexFile.add(DexFile.java:163)

at com.android.dx.command.dexer.Main.processClass(Main.java:490)

at com.android.dx.command.dexer.Main.processFileBytes(Main.java:459)

at com.android.dx.command.dexer.Main.access$400(Main.java:67)

at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:398)

at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)

at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)

at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)

at com.android.dx.command.dexer.Main.processOne(Main.java:422)

at com.android.dx.command.dexer.Main.processAllFiles(Main.java:333)

at com.android.dx.command.dexer.Main.run(Main.java:209)

at com.android.dx.command.dexer.Main.main(Main.java:174)

at com.android.dx.command.Main.main(Main.java:91)

I obviously tried the mavenLocal thing and compiling works, but building does not.

Is there a way to specify dependencies { provided  'com.google:android-support-v4:0.1'} ?

cheers

- Rainer

Am Freitag, 24. Mai 2013 22:17:47 UTC+2 schrieb Alberto Alonso Ruibal:

Traun, provisionally you can also install android-support-v4.jar to your local maven repo with:

mvn install:install-file -Dfile=android-support-v4.jar -DgroupId=com.google  -DartifactId=android-support-v4 -Dversion=0.1 -Dpackaging=jar

and then reference it from your projects build.gradle:

repositories {

    mavenLocal()

    mavenCentral()

}

dependencies {

    compile 'com.google:android-support-v4:0.1'

//...

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Manfred Moser]

On Sun, May 26, 2013 at 11:40 AM, Xavier Ducrohet <x...@android.com> wrote:

Very soon now we're going to release a repository with the support library. This means you'll be able to properly reference it as an artifact and not as a local jar file, which will make Gradle's dependency resolution able to remove duplicates.

I know a lot of people that will look forward to having this repository. Hopefully it will be in Maven 2 format so that sbt, maven and ivy users can also access it with ease.. 

manfred 

[Rainer Burgstaller]

this works now. Thanks for the hint. 

[Jonathan Steele]

This is as expected because build does merging all class into one.

On Monday, June 10, 2013 2:54:24 AM UTC-4, InTae Kim wrote:

I have similar problem about it with FACEBOOK library:

22:37:49.593 [ERROR] [org.gradle.api.Project] UNEXPECTED TOP-LEVEL EXCEPTION:

22:37:49.593 [ERROR] [org.gradle.api.Project] java.lang.IllegalArgumentException: already added: Landroid/support/v4/widget/CursorAdapter$1;

22:37:49.593 [ERROR] [org.gradle.api.Project] at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)

22:37:49.594 [ERROR] [org.gradle.api.Project] at com.android.dx.dex.file.DexFile.add(DexFile.java:163)

22:37:49.594 [ERROR] [org.gradle.api.Project] at com.android.dx.command.dexer.Main.processClass(Main.java:490)

22:37:49.594 [ERROR] [org.gradle.api.Project] at com.android.dx.command.dexer.Main.processFileBytes(Main.java:459)

22:37:49.595 [ERROR] [org.gradle.api.Project] at com.android.dx.command.dexer.Main.access$400(Main.java:67)

22:37:49.595 [ERROR] [org.gradle.api.Project] at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:398)

22:37:49.595 [ERROR] [org.gradle.api.Project] at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)

22:37:49.595 [ERROR] [org.gradle.api.Project] at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)

22:37:49.596 [ERROR] [org.gradle.api.Project] at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)

22:37:49.596 [ERROR] [org.gradle.api.Project] at com.android.dx.command.dexer.Main.processOne(Main.java:422)

22:37:49.596 [ERROR] [org.gradle.api.Project] at com.android.dx.command.dexer.Main.processAllFiles(Main.java:333)

22:37:49.596 [ERROR] [org.gradle.api.Project] at com.android.dx.command.dexer.Main.run(Main.java:209)

22:37:49.597 [ERROR] [org.gradle.api.Project] at com.android.dx.command.dexer.Main.main(Main.java:174)

22:37:49.597 [ERROR] [org.gradle.api.Project] at com.android.dx.command.Main.main(Main.java:91)

22:37:49.597 [ERROR] [org.gradle.api.Project] 1 error; aborting

Our android project structure:

/MyProject

/libs

    ...

    android-support-v4.jar

    ...

    build.gradle

    settings.gradle

/facebook

    libs/

        android-support-v4.jar

    build.gradle

and our build.gradle for dependencies block:

dependencies {

    //compile files('libs/MixpanelAPI.jar', 'libs/android-support-v4.jar', 'libs/barcode4j.jar', 'libs/gcm.jar', 'libs/libGoogleAnalyticsV2.jar', 'libs/twitter4j-core-3.0.3.jar')

    compile files('libs/MixpanelAPI.jar', 'libs/barcode4j.jar', 'libs/gcm.jar', 'libs/libGoogleAnalyticsV2.jar', 'libs/twitter4j-core-3.0.3.jar')

    compile project(':facebook')

}

What I do is just get rid of libs/adnroid-support-v4.jar from root project's build.gradle, then the build result is successful.

But I think this is not smart solution, since ant build doesn't matter library project's library dependency.

Have any good idea?

2013년 5월 29일 수요일 오후 8시 51분 13초 UTC+9, Rainer Burgstaller 님의 말:

[Pepe Paez]

This is the answer that worked for me, I have my project and it depends on 2 libraries (and by the way library b depends on library a) so what I did is I build library a with a reference to the support.jar, added it to my local maven repository, rebuild library b with a reference ONLY to library a, no reference to support.jar whatsoever, it built with no issues, added this library to maven as well and then referenced both on my main project from maven, again with no reference to support.jar

it worked.

thanks!

[Roman Mazur]

What if a jar placed in the libs directory is optional and its presence is determined in runtime by the library? Is there a way to exclude it from aar package?

[Xavier Ducrohet]

If it's determined at runtime whether the lib is needed or not, then it's still needed to be packaged in case it's needed at runtime. am I missing something?

[Roman Mazur]

Let's imagine a library that provides some Android activities and can integrate with some statistics services, let it be Flurry to illustrate. But it does so only when the app actually uses that SDK. 

We cannot get Flurry SDK jar from a repository, so that it must be placed into libs folder of our Android library. But our library does not require this jar to provide its core functionality. But now we cannot use our library without omitting Flurry SDK jar being included to application package.

I do understand that this library can be divided into two parts, like core and flurry integration. But as for me, going the described way can be useful too.

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/l1gELhPSSkM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Best regards,
Roman Mazur 

Head of Android/Java Unit at Stanfy (http://stanfy.com.ua)
Skype: roman.mazur.f

LinkedIn: http://ua.linkedin.com/in/romanmazur
Twitter: http://twitter.com/roman_mazur

[Xavier Ducrohet]

The requirement on the library is not declared at runtime in this case, so this is different from what I understood.

In this case you would add flurry as a dependency on your library but remove it from the dependencies when publishing the artifact. Then the app would have to manually include the Flurry library if they want to use it.

[Roman Mazur]

Yes, this is exactly what I want.

But can I exclude a jar in libs folder from my dependencies before publishing?

[Cheng Yang]

Hi Roman, Have you figure out how to exclude the jar befoer publishing?

[Roman Mazur]

I haven't tried to solve that particular problem, but you can try using 'provided' configuration for a local jar file.

I saw complains that local file dependencies from 'provided' configuration are still included to aar packages though.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,
Roman Mazur 

Software engineer at Stanfy (http://stanfy.com.ua)
Skype: roman.mazur.f

[John Frey]

So I'm having this same issue right now. Is there no way for a consumer of an aar library to exclude a transitive dependency buried within the /libs folder of said library? For example...

compile('com.example.mylibrary:1.0') {
    exclude module: 'android-support-v4'
    exclude module: 'date4j'
}

This doesn't work if date4j and android-support-v4 are jars inside the libs folder. 

[Parveen Kumar]

Hey John, I am facing the exact same problem. Did you find a solution?

-Parveen

[John Frey]

No. It seems we're pretty well stuck unless you can repackage the aar yourself file and remove jar from the libs folder.