2014-09-05 19 views
9

podczas kompilowania mojej aplikacji, pojawia się następujący komunikat o błędzie (wrażliwe kawałki ścieżki wycięte)Android: Klasa błędy dwóch egzemplarzach w 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])) 

Oznacza to dla mnie, że kompilator widzi dwa miejsca, w których aplikacja próbuje używać commons.codec.binary.Base64.class jako zależności. Sprawdziłem i sprawdziłem ponownie moje biblioteki, ale próbuje używać tylko jedna biblioteka (Amazon AWS).

Powyżej tego błędu, Dostaję jakieś inne ostrzeżenia, które również podnieść czerwoną flagę dla mnie:

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]) 

nie jawnie użyć Commons kodek-1.4 lub Commons lang3-3.1 w moim w ogóle, myślałem, że użyłem języka lang3, zanim go później usunę. Dlaczego są one przywoływane w dzienniku kompilacji? Czy któraś z moich mavenńskich bibliotek może ich używać? W moim pliku gradle zamieszczę poniżej listę bibliotek mavenów.

Oto moja PROGUARD i pliki Gradle dla odniesienia:

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' 
} 

Mój najlepszy przypuszczenie jest jeden lub więcej z tych bibliotek korzysta apache lang3 i kodek jako własne zależności, co powoduje konflikty t kiedy kompiluję aplikację. Ten problem występuje tylko wtedy, gdy dołączę Amazon jako wymagany słoik, więc wiem, że w pewnym sensie działa on jako winowajca, ale nie wiem, co jeszcze jest z nim sprzeczne.

Czytałem coś o użyciu -injars z PROGUARD, ale według ich dokumentacji Androida nie powinien potrzebować do wykorzystania.

Każda rada byłaby bardzo ceniona, dziękuję!

+0

Jeśli chcesz uzyskać więcej informacji o tym, co powoduje te przejściowe zależności, możesz zapytać Gradle, uruchamiając 'gradlew dependencyInsight - dependency = commons-lang3'. –

+0

Mam podobny problem. Proces kompilacji może zakończyć się bezbłędnie, ale otrzymuję ostrzeżenia związane z META-INF. – Guilherme

+0

Mam ten sam błąd tylko w uniwersalnym programie ładującym grafikę. Trochę szczęścia? – akousmata

Odpowiedz

0

Przyczyną tego problemu jest powielanie plików jar.

W katalogu projektu, spróbuj znaleźć i kasowanie

/projects/app/build/intermediates/classes-proguard/debug/classes.jar] (Nie można odczytać [/. Gradle/buforuje/moduły-2/pliki-2.1/commons-codec/commons-codec 1.4 4216af16d38465bbab0f3dff8efa14204f7a399a-codec-1.4.jar fotografia plik///

ten słoik i zobaczyć czy coś się zmieniło. również, jeśli nie ma commons-lang3 -3.1.Jar w tej samej lub górnej dirrectory, spróbuj usunąć i odbudować również.

Mam nadzieję, że to pomoże!

+0

Problem polega na tym, że próbuję czegoś takiego, a przy następnej gradacji kompilacja jest odczytywana do katalogu. – JMRboosties

+0

humm ... Myślę, że to dlatego, że albo określasz gdzieś, że projekt wymaga słoików, albo – Shawn

2

Nie jestem pewien, czy to pomoże, czy nie, ale jestem delegowania moją odpowiedź tutaj w przypadku innym znaleźć to użyteczne. Mój problem polegał na tym, że miałem 2 referencje w moim oświadczeniu o zależnościach. I był przy użyciu biblioteki Uniwersalny Loader Obraz i moje oświadczenie wyglądał następująco:

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' 
} 

Problem z tym zdałem sobie sprawę (po głowie zadatki chwilę) było to, że miałem już odwoływać UIL poprzez folderze libs (tjbyło już kompilowane przez oświadczenie compile fileTree(dir: 'libs', include: ['*.jar']). Więc kompilował go raz przez libs i raz przez wyraźne wywołanie, aby skompilować odniesienie do UIL. Usunąłem wywołanie jawne i to wyjaśniło błąd. Być może wywołujesz coś w swoim katalogu libs, który zawiera także odwołanie do biblioteki naruszającej prawa, wtedy gdy próbuje skompilować Usługi AWS, ma już wersję biblioteki wspólnej i pukes.