Android: Dex nie może przeanalizować kodu wersji 52 bajtów

93

Właśnie przełączyłem się na Android Studio 2.1 i ten błąd pojawił się podczas próby skompilowania aplikacji, która wcześniej działała:

Error:Error converting bytecode to dex:
Cause: Dex cannot parse version 52 byte code.
This is caused by library dependencies that have been compiled using Java 8 or above.
If you are using the 'java' gradle plugin in a library submodule add 
targetCompatibility = '1.7'
sourceCompatibility = '1.7'
to that submodule's build.gradle file.

Zaktualizowałem już plik gradle.build głównego projektu, aby wymusić generowanie kodu Java 1.7:

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.1.0'
        apply plugin: 'java'
        sourceCompatibility = 1.7
        targetCompatibility = 1.7
    }
}

Zaktualizowałem również moduł gradle.build w następujący sposób, aby ustawić wersję java:

android {
compileSdkVersion 19
buildToolsVersion "23.0.2"

defaultConfig {
    applicationId "com.abc.def"
    minSdkVersion 19
    targetSdkVersion 19
}

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
    }
}
compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}
}

Podmoduł budowany z Maven. W pliku pom.xml próbowałem też wymusić generowanie kodu 1.7.
Rozumiem, że używam artefaktu zespołu, który zawiera moduły podrzędne, ale nie zmieniłem żadnego z modułów podrzędnych, a wynikowy plik .jar modułu działał poprawnie podczas ostatniej kompilacji.

    <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId> <!-- maven-compiler-plugin -->
            <version>2.6</version>
            <configuration>
                <source>1.7</source>
                <target>1.7</target> 
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
            </configuration>
            <executions>
                <execution>
                    <id>make-assembly</id> <!-- this is used for inheritance merges -->
                    <phase>package</phase> <!-- bind to the packaging phase -->
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Moje pytanie: 1) Czy jest to problem z Androidem Studio 2.1? Czy inni to widzieli? 2) Zakładając, że to mój błąd i ponieważ komunikat o błędzie nie pomaga w znalezieniu złego modułu, czy są jakieś zalecenia dotyczące znalezienia kodu V52? Nie mogę po prostu pominąć bibliotek bez zrywania dużej ilości kodu. Czy można przejrzeć plik .jar, aby znaleźć wersję kodu? Z góry dziękuję. -Hefajstos

Hefajstos
źródło
1
Obecnie mam do czynienia z tym błędem. Masz szczęście do rozwiązań?
MetaSnarf
Ja też zaktualizowałem Android Studio do wersji 2.1. Od tamtej pory mam ten problem. Czy masz jakieś rozwiązanie?
Suresh Kumar
Wcześniejszy komunikat o błędzie (który od tamtej pory zniknął) sugeruje, że przyczyną problemu był plik jar pubnub. Więc wykomentowaliśmy każde odwołanie do pubnub, a teraz kompiluje się i uruchamia. Wydaje mi się, że komunikat o błędzie zniknął, kiedy dodaliśmy dyrektywy kompilatora (pokazane powyżej), aby wymusić na kodzie „1.7”, jednak wydaje się, że część kodu 1.8 nadal przeciekała.
Hefajstos
Oto kolejna dyskusja dotycząca SO, która dotyczy: stackoverflow.com/questions/36968728/… . Ale to nie daje odpowiedzi na pytanie, poza stwierdzeniem „zacznij od prostszego projektu testowego”.
Hefajstos
1
Jedyne, co zrobiliśmy, to wyciągnięcie biblioteki PubNub i zastąpienie jej starszą wersją. Wydawało się, że to naprawiło. Ale w tym przypadku przetestowaliśmy, wykomentowując import biblioteki i wywołania jej metod oraz określając, że jest to wina. Ale biblioteka PubNub była luźno zintegrowana i mogliśmy ją dość łatwo skomentować. Gdybyśmy mieli wiele bibliotek ze ścisłą integracją, byłoby to bolesne.
Hefajstos

Odpowiedzi:

89

po prostu użyj Java 1.8 z Androidem Studio 3.0+ i ustaw następujące prace dla mnie: wydaje się, że potrzebuję najnowszych narzędzi do kompilacji

classpath 'com.android.tools.build:gradle:3.0.0'

i

android {
    compileSdkVersion 26
    buildToolsVersion "26.0.1"

    defaultConfig {
        ...        
        //jackOptions { // DEPRECATED
            //enabled true
        //}
    }
    dexOptions {
        incremental true
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}
foolcage
źródło
1
Dziękuję Ci. Jednak buduję do SDK 19 i zauważam, że jesteś na 23. Myślałem, że Java 8 jest tylko dla Androida N. Nie sądzę, że mogę używać Java 8 i nadal być wstecznie kompatybilna z 19. Czy się mylę?
Hefajstos
3
Skompilowałem kod w Javie 8, kierując się na Androida N, ale uruchomiłem aplikację na Androidzie 16 bez żadnych problemów. Możesz to sprawdzić samemu
Deepscorn
7
Najwyraźniej dexOptions.incremental nie jest już wymagany, ponieważ domyślnie ma wartość true, patrz stackoverflow.com/questions/37522668
devconsole
1
Upewnij się, że rozumiesz ograniczenia związane z używaniem java 8 i że nie wszystkie funkcje języka są kompatybilne wstecz. developer.android.com/guide/platform/j8-jack.html
TrevJonez
3
Zauważ, że „ android.dexOptions.incrementalWłaściwość jest przestarzała i nie ma wpływu na proces kompilacji”.
Jonik
16

Jeśli masz moduł z biblioteką java, która nie jest specyficzna dla Androida , powinno to działać:apply plugin:'java'

Umieść go na górze pliku build.gradle, a następnie odbuduj.

    apply plugin: 'java'
    apply plugin: 'jacoco'

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

        sourceCompatibility = 1.7
        targetCompatibility = 1.7
    }
nexDev
źródło
Fajne. Dzięki. Dam temu szansę.
Hefajstos
2
Jest to właściwe rozwiązanie, jeśli masz moduł z biblioteką Java, która nie jest specyficzna dla systemu Android.
gladed
17
Błąd: zastosowano wtyczkę „java”, ale nie jest ona zgodna z wtyczkami Androida.
Alen Siljak
1
Zgoda. Wtyczka „java” jest najwyraźniej niekompatybilna z wtyczkami Androida. Brak przyjemności.
Hefajstos
1
@Alen Siljak, zastosuj wtyczkę: „nazwa Twojej wtyczki” nie musi być java.
nexDev
8

Jeśli używasz org.jetbrains:annotation:15wtyczki i retrolambda, usuń linię compile org.jetbrains:annotations:15.0ze swojego, build.gradlea błąd zniknie. Mi to pasuje.

0wl
źródło
7

Być może niektóre z Twoich zależności zostały skompilowane w Javie 8, a nie w systemie Android. Spróbuj przełączyć te zależności na starszą wersję. Nie wiem dokładnie, którą bibliotekę powinieneś obniżyć, ponieważ nie załączyłeś listy zależności swojego głównego modułu.

Na przykład: miałem ten sam problem. Po godzinach poszukiwań odkryłem, że biblioteka org.codehaus.httpcache4j.uribuilder:2.0.0wymaga Java 8, jak na github . Tak więc po przełączeniu się na 1.1.0projekt został pomyślnie skompilowany i wdrożony.

fobo66
źródło
fobo66: Tak, zgadzam się. Tak właśnie zrobiliśmy. Myślę, że niestety coraz więcej bibliotek będzie wkrótce kompilowanych z Javą 8 i będzie to częsty problem. Wygląda to tak, jak w świecie Pythona, w którym wiele bibliotek wydaje się nadal działać w wersji 2.6.
Hefajstos
Być może wkrótce przekonamy się, podobnie jak Python, że wszystkie biblioteki są dostępne osobno, zarówno w wersji J7, jak i J8.
Hefajstos
7

Spróbuj dodać do main build.gradle w sekcji allprojects

tasks.withType(JavaCompile) {
    sourceCompatibility = "1.7"
    targetCompatibility = "1.7"
}

lub dodaj to w zależnościach

    sourceCompatibility = 1.7
    targetCompatibility = 1.7

we wszystkich modułach ręcznie

vitalinvent
źródło
7

Udało mi się rozwiązać ten problem, dodając następujące wiersze:

jackOptions {
    enabled true
}

do defaultConfigw build.gradlepliku.

Możesz postępować zgodnie z wytycznymi dla Java 8 pod linkiem - https://developer.android.com/guide/platform/j8-jack.html

Faisal Ali
źródło
1
Jack jest przestarzały od 14 marca 2017 r.
nhox omija
Ten link opisuje proces usuwania jackOptions. To prawdopodobnie nie jest najlepsze rozwiązanie.
Anthony Naddeo
5

Miałem ten sam problem z zależnością greendao-generator. compile 'org.greenrobot:greendao-generator:3.1.0'Pomyłkowo dodałem tę zależność do mojej build.gradle ( ), a AndroidStudio pokazał mi ten sam komunikat o błędzie.

Prawdopodobnie dlatego, że ten moduł został skompilowany w Javie 8.

Więc usunąłem tę zależność z mojego build.gradle i wszystko skompilowałem szczęśliwie :)

Riccardo Leschiutta
źródło
2

Rozwiązałem ten problem jak poniżej:

apply plugin: 'java'

sourceCompatibility = 1.7
targetCompatibility = 1.7

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
}
李 歆 扬
źródło
2

Wyłączenie Instant Run w Android Studio 2.2 z wtyczką Gradle 2.2.2 naprawiło to za mnie. Powrót do starszej wersji wtyczki Gradle (na przykład 2.2.0) również to naprawił, ale to mniej pożądane imho.

StephanBezoen
źródło
2

Zdarzyło mi się to w Android Studio 2.3.3. Rozwiązaniem, które znalazłem, było usunięcie folderu kompilacji, a następnie odbudowanie projektu . To było takie proste.

mp501
źródło
1

Android 2.3.3Napotkałem również ten sam błąd w , po dodaniu kilku zależności JAR. Problem był spowodowany depenecją io.netty:netty-all:4.1.16.Final. Ten plik JAR w wersji 4.1.16 został skompilowany w Javie 1.8, a wszystkie inne zostały wygenerowane w Javie 1.7.

Zostało to rozwiązane po włączeniu starszej wersji programu netty(która została wygenerowana w Javie 1.7) w moim build.gradlepliku.

compile 'io.netty:netty-all:4.1.5.Final'

rashok
źródło
Przybyłem tutaj z tym samym problemem, chociaż netty page twierdzi, że java 1.6 wystarczy, aby użyć netty.
Tomasz Kryński
0

Natknąłem się na ten problem podczas próby aktualizacji do auto-value v 1.5 w Android Studio v 2.3.3. Wartość automatyczna 1,5 prawdopodobnie będzie zgodna z AS 3 (wymaga zaktualizowanego kompilatora java)

Na razie działa auto-wartość 1.4.1.

Aleksander Niedziolko
źródło
0

Zetknąłem się z tym problemem, próbując zaimportować jar skompilowany przez jdk 1.8 w Android Studio 3.0. Wypróbowałem wszystkie powyższe rozwiązania, ale żadne nie działa. więc poprosiłem programistę tego jar, aby ponownie skompilował go z jdk 1.7, a potem działa dobrze, aby nie napotkać tego problemu ponownie.

wujek długo
źródło