Android java.lang.VerifyError?

W mojej aplikacji na Androida zawsze otrzymuję VerifyErrors! I nie wiem, dlaczego. Za każdym razem, gdy dołączam zewnętrzny plik JAR, zawsze otrzymuję VerifyErrors, gdy próbuję uruchomić moją aplikację (z wyjątkiem jednego razu, gdy dołączam Apache Log4j).

Zazwyczaj omijam ten problem, pobierając źródło biblioteki i dodając je do mojego projektu, ale próbuję umieścić bibliotekę klienta GData .

Mogę to uzyskać w źródle, ale jego zależności (mail.jar, aktywacja.jar, servlet-api.jar) nie mogę, więc otrzymuję błędy weryfikacji. Chciałbym raz na zawsze dotrzeć do źródła tego problemu. Szukałem w Internecie, ale wydaje się, że wszyscy mówią o niekompletnych plikach zajęć? których nie wiem.

Android używa innego formatu plików klas. Czy korzystasz z plików JAR innych firm za pomocą narzędzia „dx”, które jest dostarczane z pakietem Android SDK?

Spójrz na LogCat i zobacz, co powoduje błąd weryfikatora. Prawdopodobnie jest to metoda w klasie java.lang, która nie jest obsługiwana na używanym poziomie zestawu SDK systemu Android (na przykład String.isEmpty ()).

Od twórców Androida :

Dane wyjściowe z „adb logcat” wskazują klasę, której nie można znaleźć, oraz klasę, która ma błędne odniesienie. Lokalizacja jest określona zgodnie z konkretnymi instrukcjami Dalvik. Sztuczka polega na zajrzeniu do dzienników nad wyjątkiem.

Aby to działało, musisz dodać jar biblioteki do jednego z folderów źródłowych (nawet jeśli już dodałeś go jako bibliotekę eclipse, nadal musisz dodać go jako źródło).

1. Utwórz katalog w swoim projekcie (np. „Libs”) i umieść tam jar biblioteki.
2. Dodaj katalog do ścieżki klasy kompilacji (kliknij prawym przyciskiem myszy na folderze i wybierz „Ścieżka kompilacji” -> „Użyj jako folderu źródłowego”).
3. Odbuduj swój projekt.

Przydarzyło mi się to teraz. Błąd został spowodowany, ponieważ korzystałem z metod z nowszego zestawu SDK, który posiadało moje urządzenie.

Urządzenie z Androidem 1.5 zainstalowało apk, używając tego:

<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/>

Znalazłem interesujący przypadek. Używam:

<uses-sdk
   android:minSdkVersion="9"
   android:targetSdkVersion="18" />

Tak więc niektóre z nowych możliwości Androida 4 nie zostały zaimplementowane w Androidzie 2.3, jak ImageView.setLayerType. Aby uniknąć błędów w czasie wykonywania, po prostu:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
   setLayerType(View.LAYER_TYPE_SOFTWARE, null);
}

To podejście powinno być stosowane również z obsługą wyjątków:

} catch (NetworkOnMainThreadException nomte) {
   // log this exception
} catch (SocketTimeoutException socketTimeoutException) {
   // log this exception
}

NetworkOnMainThreadExceptionnie jest zaimplementowana w systemie Android 2.3, więc po załadowaniu klasy (a nie wcześniej!) java.lang.VerifyErrorwystępuje wyjątek .

Jeśli używasz Retrolambda, mogłeś dodać statyczną metodę do interfejsu (która jest dozwolona tylko w Javie 8).

Może to również wystąpić z powodu błędu limitu odniesienia w Lollypop poniżej wersji, w których jest ograniczony do maksymalnego rozmiaru 65K

Możliwe rozwiązanie powyższego problemu

Krok 1: Add android-support-multidex.jar to your project. The jar can be found in your Android SDK folder /sdk/extras/android/support/multidex/library/libs

Krok 2: Rozszerz swoją aplikację o MultiDexApplication, np

public class MyApplication extends MultiDexApplication

Krok 3: Zastąp attachBaseContext

protected void attachBaseContext(Context base) {
 super.attachBaseContext(base);
 MultiDex.install(this);
}

Krok 4: Następnym krokiem jest dodanie następujących elementów do części Android aplikacji build.gradle

 dexOptions {
      preDexLibraries = false
   }

Krok 5: Na koniec, postępując zgodnie z ogólną częścią twoich aplikacji build.gradle

afterEvaluate {
   tasks.matching {
      it.name.startsWith('dex')
   }.each { dx ->
      if (dx.additionalParameters == null) {
         dx.additionalParameters = ['--multi-dex']
      } else {
         dx.additionalParameters += '--multi-dex'
      }
   }
}

Aby uzyskać szczegółowe informacje, przejdź do kasy

https://developer.android.com/tools/building/multidex.html

W moim przypadku stało się tak, gdy zaktualizowałem Eclipse Indigo do Eclipse Juno: nie jestem pewien, jaki jest prawdziwy powód, ale mój projekt na Androida, nad którym pracuję od dłuższego czasu, przestał działać z powodu tego wyjątku.

Po wielu godzinach próby rozwiązania tego problemu znalazłem rozwiązanie dla siebie.

W moim projekcie Android używam innego projektu (na przykład „MyUtils”), który znajduje się w tym samym obszarze roboczym. Musiałem więc wykonać następujące czynności:

Kliknij prawym przyciskiem myszy projekt systemu Android -> Ścieżka kompilacji -> Konfiguruj ścieżkę kompilacji

Teraz przejdź do zakładki „Zamów i eksportuj” i zaznacz pole „MyUtils”. To wszystko: pozbyłem się tego irytującego wyjątku.

Zmniejszam wersję Gradle z 2.0.0-alpha2 do 1.5.0, która rozwiązała ten problem.

Problem może być również spowodowany niezgodnością między dwoma projektami androidów. Na przykład, jeśli opracowałeś bibliotekę dla Androida przy użyciu pakietu „com.twojafirma”, masz projekt aplikacji głównej korzystający z tego samego pakietu co pakiet podstawowy. Następnie powiedzmy, że chcesz zmienić wersję swojej głównej aplikacji, więc zmień wartości pliku manifestu: kod wersji i nazwę wersji. Jeśli uruchomisz aplikację bez zmiany tych wartości dla biblioteki, otrzymasz błąd weryfikacji przy każdym wywołaniu metody na obiekcie z biblioteki.

Miałem ten sam problem. Budowałem z 2.1 r1 i zaktualizowałem do 2.1 r3 z nowym adt 17. Miałem błędy weryfikacji w mail.jar javamaila i doprowadzało mnie to do szału. Oto jak rozwiązałem problem:

1. utworzył folder libs / i dodał pliki jars.
2. kliknij prawym przyciskiem myszy> dodaj jako folder źródłowy

próbowałem odbudować i się nie udało. Usunąłem katalog libs / jako folder źródłowy i usunąłem odniesienia do 3 plików jar w ścieżce kompilacji. Następnie ponownie dodałem folder libs / i dodałem każdy jar w folderze libs / do ścieżki kompilacji. Teraz działa zgodnie z oczekiwaniami. To dziwne obejście, ale zadziałało.

W Eclipse 4.x, jeśli napotkasz ten problem, spróbuj poniżej:

1. przenieść wszystkie dołączone słoiki innych firm do User-Libaray
2. przenieś bibliotekę użytkownika w górę przed biblioteką Androida i sprawdź ją na karcie Zamów i eksportuj
3. wyczyść i przebuduj, aby działać

Mam ten problem po aktualizacji SDK. Kompilator miał problemy z moimi zewnętrznymi bibliotekami. Zrobiłem to: kliknij prawym przyciskiem myszy projekt, a następnie „Android Tools> dodaj bibliotekę wsparcia…” ta instalacja w mojej bibliotece projektów „android-support-v4.jar”.

java.lang.VerifyErroroznacza, że ​​skompilowany kod bajtowy odnosi się do czegoś, czego Android nie może znaleźć w czasie wykonywania. Ten verifyError Występuje tylko z KitKat4.4 i mniejszą wersją, której nie ma w powyższej wersji , nawet jeśli uruchomiłem tę samą kompilację na obu urządzeniach. kiedy użyłem parsera json json starszej wersji, to pokazujejava.lang.VerifyError

compile 'com.fasterxml.jackson.core:jackson-databind:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-core:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-annotations:2.2.+'

Następnie zmieniłem Dependancy na najnowszą wersję 2.2 na 2.7 bez biblioteki core (kiedy dołączam core2.7 daje to verifyError), to działa. co oznacza, że ​​metody i inne treści rdzenia są migrowane do najnowszej wersji Databind2.7 . To naprawi moje problemy.

compile 'com.fasterxml.jackson.core:jackson-annotations:2.7.0-rc3'
compile 'com.fasterxml.jackson.core:jackson-databind:2.7.0-rc3'

Dostaję również VerfiyError ... nie mogę znaleźć prawdziwego powodu. Pomaga zawinąć nowe wiersze kodu w metodę (Eclipse, „Wyodrębnij metodę…”). Więc w moim przypadku powodem nie jest nieobsługiwana metoda.

Miałem bardzo podobny problem. Dodałem jary Apache POI i pojawił się problem po aktualizacji do Android SDK 22.3.

Sprawdziłem prywatne biblioteki Androida, więc nie był to częsty problem z Android SDK. Odznaczyłem wszystkie słoiki Apache POI i dodałem jeden po drugim. Okazało się, że poi-3.9-20121203.jar powinien znajdować się przed poi-ooxml-3.9-20121203.jar . W przeciwnym razie to nie zadziała.

Jeśli masz testy, spróbuj wykomentować tę linię ze swojego build.gradepliku:

testCoverageEnabled = true

Dla mnie spowodowało to wyjątki VerifyError w klasach, które używają funkcji Java 1.7, szczególnie w instrukcjach przełączania ciągów.

Miałem ten sam problem po wykonaniu git pull.

Rozwiązanie: Kompiluj -> Wyczyść projekt.

Mam nadzieję że to pomoże.

Znalazłem inny przypadek.

Warunki:

• Użyj Retrolambda (nie wiem, czy to konieczne);
• Utwórz metodę statyczną w interfejsie.

Rezultatem jest boom! java.lang.VerifyError podczas próby uzyskania dostępu do klasy używającej tego interfejsu. Wygląda na to, że Android (4.4. * W moim przypadku) nie lubi statycznych metod w interfejsach. Usunięcie metody statycznej z interfejsu powoduje zniknięcie VerifyError.

Ja też miałem ten problem, podobnie jak moje słoiki w bibliotece użytkownika ...

Sposób, w jaki to rozwiązałem, polegał na dodaniu ich do folderu lib, a następnie dodaniu ich we właściwościach kompilacji w eclipse ...

Za pierwszym razem nie zadziałało, ale potem je usunąłem i ponownie przeczytałem i zaczęło działać ...

trochę dziwny! ale teraz pracuje cały czas.

Powodzenia

Zakodowałem metody / klasy Android API, które są w SDK 2.1 i próbowałem uruchomić je na emulatorze Androida 1.6. Więc mam ten błąd.

ROZWIĄZANIE: Zmieniono to na poprawną wersję emulatora.

TO DZIAŁAŁO DLA MNIE .. Dzięki.

Dla potomności właśnie otrzymałem ten błąd, ponieważ używałem metody, Arrays.copyOf()która nie jest obsługiwana przez Javę 1.5, która odpowiada poziomowi Androida 4. Ponieważ pracowałem z bibliotekami opracowanymi pod 1.6, skompilowały się dobrze. Zobaczyłem problemy dopiero po przeniesieniu danej klasy do mojego projektu na Androida - wtedy błąd został podświetlony.

Uncaught handler: thread main exiting due to uncaught exception
java.lang.VerifyError: com.j256.ormlite.dao.BaseDaoImpl$DaoConfigArray
  at com.j256.ormlite.dao.BaseDaoImpl$1.initialValue(BaseDaoImpl.java:71)
  at com.j256.ormlite.dao.BaseDaoImpl$1.initialValue(BaseDaoImpl.java:1)
  at java.lang.ThreadLocal$Values.getAfterMiss(ThreadLocal.java:429)
  at java.lang.ThreadLocal.get(ThreadLocal.java:66)

W tej linii próbowałem zrobić new DaoConfigArraya ta klasa miała następującą linię:

// copyOf is only supported in Java >= 1.6
doArray = Arrays.copyOf(daoArray, newLength);

Jeszcze bardziej skomplikowane jest to, że wiersz 71 wskazywał na ThreadLocalinicjalizację, o której myślałem, że jest przyczyną problemu.

private static final ThreadLocal<DaoConfigArray> daoConfigLevelLocal
    = new ThreadLocal<DaoConfigArray>() {
    @Override
    protected DaoConfigArray initialValue() {
        return new DaoConfigArray();
    }
};

Musiałem usunąć projekty zależne, a zamiast tego skompilować projekty zależne od jar i dołączyć je do folderu libs.

Jestem pewien, że moja sprawa była inna niż twoja, ale ponieważ jest to jeden z największych hitów podczas wyszukiwania hasła „java.lang.VerifyError na Androida”, pomyślałem, że nagram to tutaj dla potomności.

Miałem kilka zajęć w stylu:

public class A { ... }
public class B extends A { ... }
public class C extends A { ... }

I metoda, która zrobiła:

A[] result = null;
if (something)
    result = new B[cursor.getCount()];
else
    result = new C[cursor.getCount()];

// Fill result
...

Tak długo, jak ten kod był obecny w pliku, otrzymywałbym VerifyError przy pierwszym załadowaniu klasy zawierającej tę metodę. Podzielenie go na dwie oddzielne metody (jedna, która dotyczyła tylko B, a druga dotyczyła tylko C) rozwiązało problem.

W moim przypadku ten błąd występuje, ponieważ moja usługa Google Play nie jest najnowsza .

Jeśli Twój projekt nie obsługuje jakiejś klasy w .jar, występuje ten błąd (np. ImageView.setLayerType, AdvertisingIdClient itp.).

Właśnie zidentyfikowałem inną sytuację, która występuje, nie tylko z powodu libs, a nie dx 'ed. Mam AsyncTask z bardzo długim mehtodem doInBackground. Z jakiegoś powodu ta metoda z ponad 145 liniami zaczęła pękać. Stało się to w aplikacji 2.3. Kiedy po prostu zamknąłem niektóre części w metodach, działało dobrze.

Więc dla tych, którzy nie mogli znaleźć klasy, która nie została poprawnie dx 'ed, spróbuj skrócić długość swojej metody.

Dla mnie problem polegał na tym, że użyłem klauzuli multi-catch gdzieś w klasie, która jest funkcją Java 7 (i API 19+). Więc zawiesiłoby się VerifyErrorna wszystkich urządzeniach starszych niż 19.

Dla mnie było to w korelacji między compileSdkVersion i buildToolsVersion. Miałem:

compileSdkVersion 21
buildToolsVersion '19.1.0'

Zmieniłem to na:

compileSdkVersion 21
buildToolsVersion '21.1.2'

Dla mnie jest to problem compileSdkVersion. Kiedy użyłem poziomu API 21 w określonej aplikacji na Androida ( https://github.com/android10/Android-AOPExample ):

compileSdkVersion 21

wystąpił błąd java.lang.verifyerror. Więc zmieniłem compileSdkVersion na 19

compileSdkVersion 19

Działało dobrze. Myślę, że może to być problem SDK buildTools i wydaje się OK, gdy poziom API <21.