2014-09-05 19 views
9

quando si compila la mia app, ottengo il seguente errore (pezzi sensibili del percorso a cura fuori)Android: errori di classe duplicate in Proguard

Execution failed for task ':app:proguardDebug'. 
> java.io.IOException: Can't write [/projects/app/build/intermediates/classes-proguard/debug/classes.jar] (Can't read [/.gradle/caches/modules-2/files-2.1/commons-codec/commons-codec/1.4/4216af16d38465bbab0f3dff8efa14204f7a399a/commons-codec-1.4.jar(;;;;;;!META-INF/MANIFEST.MF)] (Duplicate zip entry [commons-codec-1.4.jar:org/apache/commons/codec/binary/Base64.class])) 

Questo indica a me che il compilatore vede due luoghi in cui l'applicazione sta cercando utilizzare commons.codec.binary.Base64.class come dipendenza. Ho controllato e ricontrollato le mie librerie, ma solo una libreria (Amazon AWS) sta tentando di usarla.

Sopra questo errore, mi sto alcune altre avvertenze che sollevano anche una bandiera rossa per me:

Warning:can't write resource [META-INF/LICENSE.txt] (Duplicate zip entry [commons-lang3-3.1.jar:META-INF/LICENSE.txt]) 
Warning:can't write resource [META-INF/NOTICE.txt] (Duplicate zip entry [commons-lang3-3.1.jar:META-INF/NOTICE.txt]) 
Warning:can't write resource [META-INF/LICENSE.txt] (Duplicate zip entry [commons-codec-1.4.jar:META-INF/LICENSE.txt]) 
Warning:can't write resource [META-INF/NOTICE.txt] (Duplicate zip entry [commons-codec-1.4.jar:META-INF/NOTICE.txt]) 

Non faccio uso esplicitamente commons-codec-1.4 o commons-lang3-3.1 nel mio app, pensavo che usassi lang3 prima di rimuoverlo. Perché vengono referenziati nel registro di compilazione? Potrebbe una delle mie librerie di esperti usarle? Includerò un elenco di librerie di maven di seguito nel mio file gradle.

Ecco la mia Proguard e file Gradle per riferimento:

PROGUARD

-keep class org.w3c.dom.bootstrap.** { *; } 
-keep class org.joda.time.** { *; } 
-keep class com.facebook.** { *; } 
-keep class org.apache.commons.** { *; } 
-renamesourcefileattribute SourceFile 
-keepattributes SourceFile,LineNumberTable 
-dontwarn org.codehaus.jackson.map.ext.** 
-dontwarn oauth.** 
-dontwarn com.amazonaws.** 
-dontwarn org.joda.time.** 
-dontwarn org.apache.commons.codec.** 
-dontwarn com.fasterxml.jackson.databind.ext.** 

Gradle

apply plugin: 'com.android.application' 

android { 
    compileSdkVersion 20 
    buildToolsVersion '20.0.0' 

    defaultConfig { 
     applicationId 'com.my.package' 
     minSdkVersion 14 
     targetSdkVersion 20 
     versionCode 9 
     versionName '1.2' 
    } 

    buildTypes { 
     release { 
      debuggable false 
      runProguard true 
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt' 
     } 
     debug { 
      debuggable true 
      runProguard true 
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt' 
     } 
    } 

    lintOptions { 
     checkReleaseBuilds false 
    } 

    packagingOptions { 
     exclude 'META-INF/LICENSE.txt' 
     exclude 'META-INF/NOTICE.txt' 
     exclude 'META-INF/MANIFEST.MF' 
    } 
} 

dependencies { 
    compile fileTree(dir: 'libs', include: ['*.jar']) 

    //noinspection GradleDependency 
    compile 'com.google.android.gms:play-services:5.0.89' 

    compile 'com.nineoldandroids:library:2.4.0' 
    compile 'com.viewpagerindicator:library:[email protected]' 
    compile 'se.emilsjolander:StickyScrollViewItems:1.1.0' 
    compile 'se.emilsjolander:stickylistheaders:2.5.0' 
    compile 'com.nostra13.universalimageloader:universal-image-loader:1.9.2' 
    compile project(':facebook') 
    compile 'com.tumblr:jumblr:0.0.10' 
    compile 'com.android.support:support-v4:20.0.0' 
} 

La mia ipotesi migliore è uno o più di tali librerie sta usando apache lang3 e codec come dipendenze proprie, che risulta in un conflitto t quando compilo l'app. Questo problema si verifica solo quando includo Amazon come jar richiesto, quindi so che in qualche modo agisce da colpevole, ma non so che altro sia in conflitto con esso.

Ho letto qualcosa sull'utilizzo di -injars con proguard, ma secondo la loro documentazione Android non dovrebbe aver bisogno di usarlo.

Qualsiasi consiglio sarebbe molto apprezzato, grazie!

+0

Se si desidera ottenere ulteriori informazioni su ciò che causa queste dipendenze transitive, è possibile chiedere a Gradle eseguendo 'gradlew dependencyInsight --dependency = commons-lang3'. –

+0

Sto riscontrando un problema simile. Il processo di compilazione può terminare senza errori, ma ricevo gli avvertimenti relativi a META-INF – Guilherme

+0

Ho lo stesso errore solo sul caricatore universale di immagini. Qualche fortuna? – akousmata

risposta

0

La causa di questo problema è la duplicazione dei file jar.

nella directory del progetto, provare a trovare e la cancellazione

/projects/app/build/intermediates/classes-proguard/debug/classes.jar] (Impossibile leggere [/. Gradle/cache/moduli-2/file-2.1/commons-codec/commons-codec/1,4//-codec-1.4.jar comuni file di

questo barattolo 4216af16d38465bbab0f3dff8efa14204f7a399a e vedere se qualcosa cambia. Inoltre, se non v'è commons-lang3 -3.1.jar nella dirrectory uguale o superiore, prova a cancellarlo e a ricostruirlo.

Spero che aiuti!

+0

Il problema è quando provo qualcosa del genere, al successivo gradle build viene letto nella directory. – JMRboosties

+0

humm ... Penso che sia perché o stai specificando da qualche parte che il progetto richiede quei barattoli, o – Shawn

2

Non sono sicuro se questo ti sarà d'aiuto o meno, ma sto postando la mia risposta qui nel caso in cui altri lo trovino utile. Il mio problema era che avevo 2 riferimenti nella mia dichiarazione delle dipendenze. Stavo usando la biblioteca universale immagine Loader e la mia dichiarazione si presentava così:

dependencies { 
    compile fileTree(dir: 'libs', include: ['*.jar']) 
    compile 'com.android.support:appcompat-v7:22.1.1' 
    compile 'com.android.support:support-v4:22.1.1' 
    compile 'uk.co.chrisjenx:calligraphy:2.0.2' 
    /* UIL was the failing reference */ 
    compile 'com.nostra13.universalimageloader:universal-image-loader:1.9.3' 
    compile 'com.google.android.gms:play-services:7.3.0' 
} 

Il problema di questo mi sono reso conto (dopo un momento schiaffo testa) era che avevo già fatto riferimento UIL tramite la cartella libs (vale a direera già stato compilato dalla dichiarazione compile fileTree(dir: 'libs', include: ['*.jar']). Quindi lo stava compilando una volta tramite libs e una volta tramite la chiamata esplicita per compilare il riferimento a UIL. Ho rimosso la chiamata esplicita e questo ha chiarito l'errore. Forse stai chiamando qualcosa nella tua directory libs che contiene anche un riferimento alla libreria incriminata, quindi quando tenta di compilare i Servizi AWS ha già una versione della libreria di comuni e vomita.

Problemi correlati