Android java.lang.VerifyError?

100

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.

Isaac Waller
źródło
Wiadomo, że GData nie działa w systemie Android. Wyszukaj temat w grupie Google dla programistów Androida. Musimy poczekać na oficjalne GData dla Androida w przyszłej wersji SDK.
mparaz
1
Czy używasz Gradle do tworzenia projektu? Miałem ten problem, gdy zapomniałem uruchomić czystego zadania przed zadaniem asemblera ...
IgorGanapolsky

Odpowiedzi:

35

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?

TofuBeer
źródło
4
Byłoby wspaniale, gdybyśmy mieli więcej informacji na temat narzędzia „dx”.
Daniel Magnusson
2
Zajrzyj do sekcji „Biblioteka” w ustawieniach projektu na Androida pod listą wersji SDK. Czy Twoje zewnętrzne projekty, na których polegasz w swojej kompilacji, są tam widoczne, z zielonym ptaszkiem obok nich?
Adam
@Adam DZIĘKUJEMY za ten komentarz! Właśnie rozwiązałeś problem, który spędziłem zbyt dużo czasu próbując go rozwiązać.
Simon Forsberg
118

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 ()).

Alex
źródło
4
Należy to oznaczyć jako prawdziwą odpowiedź. Przynajmniej tak było w moim przypadku, ponieważ otrzymywałem sporadyczne błędy od moich użytkowników i wyśledziłem je do wywołania View.getTag (int), które nie jest obsługiwane w wersji 3 interfejsu API
Bostone
1
Zgoda. Spotkałem się z tym kilka razy i za każdym razem celuję w 2.xi używam czegoś, co nie jest w wersji 1.5. To, co cię wyrzuca, to wyrzucanie, gdy klasa jest tworzona / używana po raz pierwszy, więc jeśli zdarza się to sporadycznie, możesz tego nie zauważyć przez chwilę.
mbafford
„To powinno być oznaczone jako prawdziwa odpowiedź”. Przeszedłem przez ten wątek, ponieważ mam ten sam problem. Domyślam się, że powodem, dla którego nie zostało to oznaczone jako prawdziwa odpowiedź, jest to, że LogCat podaje odwołanie do wiersza do miejsca, w którym tworzę wystąpienie biblioteki, ale nie do wiersza, w którym problem jest spowodowany. Innymi słowy, w tym przypadku LogCat jest prawie bezużyteczny.
NotACleverMan
logcat na poziomie WARN powinien pokazać szczegóły, dlaczego nie udało się zweryfikować
mmeyer
56

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.

ADB
źródło
6
Powyższe spojrzenie na wyjątek pomogło mi również w zidentyfikowaniu metody powodującej błąd. Dla mnie było to wyrażenie Build.VERSION.SDK_INT> = Build.VERSION_CODES.ECLAIR, co jest dość oczywiste, w końcu, jeśli spróbujesz tego na Cupcake ...
Manuel
2
Dzięki! To był problem, który otrzymywałem ... przydatne dzienniki były tuż nad wyjątkiem: WARN/dalvikvm(1052): VFY: unable to resolve static method 475: Ljavax/xml/datatype/DatatypeFactory;.newInstance ()Ljavax/xml/datatype/DatatypeFactory;(teraz, aby dowiedzieć się, jak to zrobić bez DatatypeFactory)
pyko 24.04.11
Spojrzenie powyżej błędu też mi pomogło. Poszukaj wiadomości zaczynającej się od „VFY:” W moim przypadku było to napisane „arbitralne odrzucanie dużej metody”. Zapewne dlatego, że tworzy ogromną ilość tablic :) Tak czy inaczej, dzięki za cynk!
Amplify91
Dzięki! Okazało się, że mój problem dotyczy obsługi wyjątków: NetworkOnMainThreadException nie jest zaimplementowany w systemie Android 2.3. Spójrz na moją odpowiedź. Dzięki jeszcze raz! :)
Seraphim's
Dzięki! W moim przypadku celowałem w system Android2.3 i używałem android-support-v4.jar i nie znajdowałem klas w tym jaru. Musiałem kliknąć zakładkę „eksport” dla tej klasy we właściwościach i przenieść ją powyżej biblioteki android2.3.3. Cóż, ten eksport jest naprawdę czymś, czego nie rozumiem jasno ...
xtof54
14

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.
Maksim Golivkin
źródło
Czy możemy dodać „Bibliotekę projektów” zamiast JAR do folderu „libs”?
Ahmed
Dziwne ... Musiałem dodać ją jako zwykłą bibliotekę Java - a nie jako bibliotekę w menu „Android” w Eclipse.
Phil
Dzięki Maksim, fajne rozwiązanie.
Arun Badole
8

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"/>
Macarse
źródło
8

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 .

Serafinów
źródło
1
To samo stało się ze mną. Użyłem, java.lang.ReflectiveOperationExceptionco nie jest zawarte w starszych wersjach Androida (na przykład 4.2), ale Lint nie ostrzegł mnie o tym ...
WonderCsabo
Dla mnie problem polega na tym, że mój kod deklaruje a CameraAccessException, co jest wprowadzane w systemie Android 5.0, ale kiedy uruchamiam na urządzeniu z Androidem 4.3, wyrzucany jest VerifyError.
Piasy
7

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

Takhion
źródło
7

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

Pawan Maheshwari
źródło
Pracował dla mnie !! nie zapomnij zmienić klasy aplikacji na „MultiDexApplication”.
Ganesh
Uratowałeś mnie, stary. To powinna być akceptowana odpowiedź.
Rohit Rokde
3

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.

Dmitry Frank
źródło
To właśnie rozwiązało problem… mamy duży projekt, więc obejrzałem go i po prostu sprawdziłem na wszystkim flagę „eksport”. Problem z PITA.
Someone Somewhere
3

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

Sun Zhengchang
źródło
2

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.

Zero jeden
źródło
2

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.

ThumbsDP
źródło
2

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ć
user1691964
źródło
2

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”.

Andreu
źródło
2

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'
anand krish
źródło
1

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.

asdf wer
źródło
1

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.

Grzegorz Bielański
źródło
1

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.

aluxian
źródło
1

Miałem ten sam problem po wykonaniu git pull.

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

Mam nadzieję że to pomoże.

Vingtoft
źródło
1
Naprawdę nic nie ciągnął ani nie robił, ale zrobił to czysty, dzięki!
Alexandre G
1

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.

Wyświetlana nazwa
źródło
0

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

Benjamin Lambe
źródło
0

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.

Piyush Patel
źródło
0

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();
    }
};
Szary
źródło
0

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

Siddharth
źródło
0

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.

benkc
źródło
1
Nawiasem mówiąc, sposób, w jaki spowodowałem rootowanie, polegał na komentowaniu treści metod (zastępując zwracanie wartości null / 0 / false) do momentu zniknięcia błędu VerifyError, a następnie przywracaniu rzeczy, dopóki nie powrócą; następnie robiąc to samo w ramach metody problemu. Z pewnością niezbyt przyjemny sposób debugowania, ale zadziałał.
benkc
0

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

Allen
źródło
0

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.

Rafael Coutinho
źródło
0

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.

Jin
źródło
0

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'
gingo
źródło
0

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.

Lilin
źródło