Android java.lang.VerifyError?


100

In meiner Android-App bekomme ich immer VerifyErrors! Und ich kann nicht herausfinden warum. Wenn ich eine externe JAR einbinde, erhalte ich immer VerifyErrors, wenn ich versuche, meine App zu starten (außer einmal, wenn ich Apache Log4j eingefügt habe).

Normalerweise umgehe ich das, indem ich die Quelle der Bibliothek nehme und sie meinem Projekt hinzufüge, aber ich versuche, die GData-Clientbibliothek zu platzieren .

Ich kann dies in der Quelle abrufen, aber es sind Abhängigkeiten (mail.jar, activity.jar, servlet-api.jar), die ich nicht kann, daher erhalte ich Überprüfungsfehler. Ich möchte diesem Problem ein für alle Mal auf den Grund gehen. Ich habe im Internet gesucht, aber alle scheinen über unvollständige Klassendateien zu sprechen? was ich nicht weiß.


Es ist bekannt, dass GData unter Android nicht funktioniert. Suchen Sie in der Google-Gruppe für Android-Entwickler nach dem Thema. Wir müssen in einer zukünftigen SDK-Version auf eine offizielle GData für Android warten.
Mparaz

1
Verwenden Sie Gradle, um Ihr Projekt zu erstellen? Ich hatte dieses Problem, als ich vergaß, die saubere Aufgabe vor dem Zusammenbau
auszuführen. Release-

Antworten:


35

Android verwendet ein anderes Klassendateiformat. Führen Sie die JAR-Dateien von Drittanbietern über das mit dem Android SDK gelieferte Tool "dx" aus?


4
Wäre toll mit ein paar Infos zum "dx" Tool.
Daniel Magnusson

2
Schauen Sie im Abschnitt "Bibliothek" der Android-Projekteinstellungen unter der Liste der SDK-Versionen nach. Werden Ihre externen Projekte, auf die Sie sich in Ihrem Build verlassen, dort mit einem grünen Häkchen angezeigt?
Adam

@ Adam DANKE für diesen Kommentar! Sie haben gerade ein Problem gelöst, für das ich viel zu viel Zeit aufgewendet habe.
Simon Forsberg

118

Schauen Sie sich LogCat an und sehen Sie, was den Verifizierungsfehler verursacht. Es ist wahrscheinlich eine Methode in einer java.lang-Klasse, die auf der von Ihnen verwendeten Android SDK-Ebene nicht unterstützt wird (z. B. String.isEmpty ()).


4
Dies sollte als echte Antwort markiert werden. Zumindest was es genau in meinem Fall war, da ich sporadische Fehler von meinen Benutzern bekam und es bis zum Aufruf von View.getTag (int) aufspürte, der in Version 3 von API
Bostone

1
Einverstanden. Ich bin ein paar Mal darauf gestoßen und jedes Mal ziele ich auf 2.x und verwende etwas, das nicht in 1.5 enthalten ist. Was Sie abschreckt, ist, dass es ausgelöst wird, wenn die Klasse nur zum ersten Mal erstellt / verwendet wird. Wenn dies also sporadisch geschieht, werden Sie es möglicherweise eine Weile nicht bemerken.
Mbafford


"Dies sollte als echte Antwort markiert werden." Ich bin auf diesen Thread gestoßen, weil ich das gleiche Problem habe. Ich vermute, der Grund, warum dies nicht als die eigentliche Antwort markiert wurde, ist, dass LogCat einen Zeilenverweis darauf gibt, wo ich eine Instanz einer Bibliothek erstelle, aber nicht auf die Zeile, in der das Problem verursacht wird. Mit anderen Worten, in diesem Fall ist LogCat nahezu nutzlos.
NotACleverMan

logcat auf WARN-Ebene sollte Ihnen die Details zeigen, warum die Überprüfung fehlgeschlagen ist
mmeyer

56

Von Android-Entwicklern :

Die Ausgabe von "adb logcat" gibt die Klasse an, die nicht gefunden werden konnte, sowie die Klasse, die die falsche Referenz hat. Der Ort wird bis zur spezifischen Dalvik-Anweisung identifiziert. Der Trick besteht darin, in den Protokollen über der Ausnahme nachzuschauen.


6
Ein Blick über die Ausnahme hat mir auch geholfen, die Methode zu identifizieren, die den Fehler verursacht hat. Für mich war es der Ausdruck Build.VERSION.SDK_INT> = Build.VERSION_CODES.ECLAIR, der am Ende ziemlich offensichtlich ist, wenn Sie das auf Cupcake versuchen ...
Manuel

2
Vielen Dank! Dies war das Problem, das ich bekam ... die nützlichen Protokolle waren nur über der Ausnahme: WARN/dalvikvm(1052): VFY: unable to resolve static method 475: Ljavax/xml/datatype/DatatypeFactory;.newInstance ()Ljavax/xml/datatype/DatatypeFactory;(jetzt, um herauszufinden, wie man ohne DatatypeFactory
auskommt

Ein Blick über den Fehler hat mir auch geholfen. Suchen Sie nach einer Nachricht, die mit "VFY:" beginnt. In meinem Fall heißt es "willkürlich große Methode ablehnen". Wahrscheinlich, weil es eine große Anzahl von Arrays erstellt :) Wie auch immer, danke für den Tipp!
Amplify91

Vielen Dank! Ich habe festgestellt, dass mein Problem im Ausnahmebehandler liegt: NetworkOnMainThreadException ist in Android 2.3 nicht implementiert. Schau nach unten für meine Antwort. Danke noch einmal! :)
Seraphim

Vielen Dank! In meinem Fall habe ich auf Android2.3 abgezielt und die android-support-v4.jar verwendet, und es wurden keine Klassen in dieser JAR gefunden. Ich musste in den Eigenschaften auf die Registerkarte "Exportieren" für diese Klasse klicken und sie über die android2.3.3-Bibliothek bringen. Nun, dieser Export ist wirklich etwas, das ich nicht klar verstehe ...
xtof54

14

Damit es funktioniert, müssen Sie jar der Bibliothek zu einem der Quellordner hinzufügen (auch wenn Sie es bereits als Eclipse-Bibliothek hinzugefügt haben, müssen Sie es dennoch als Quelle hinzufügen).

  1. Erstellen Sie ein Verzeichnis in Ihrem Projekt (ex "libs") und legen Sie dort das Bibliotheksglas ab.
  2. Fügen Sie das Verzeichnis dem Buildklassenpfad hinzu, indem Sie (klicken Sie mit der rechten Maustaste auf den Ordner und wählen Sie "Buildpfad" -> "Als Quellordner verwenden").
  3. Erstellen Sie Ihr Projekt neu.

Können wir dem Ordner 'libs' eine "Projektbibliothek" anstelle einer JAR hinzufügen?
Ahmed

Seltsam ... Ich musste es als normale Java-Bibliothek hinzufügen - nicht als Bibliothek unter dem Menü "Android" in Eclipse.
Phil

Danke Maksim, schöne Lösung.
Arun Badole

8

Es ist mir gerade passiert. Der Fehler wurde verursacht, weil ich Methoden aus einem neueren SDK verwendete, über das mein Gerät verfügte.

Android 1.5 Gerät installiert eine apk mit diesem:

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

8

Ich habe einen interessanten Fall gefunden. Ich benutze:

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

Daher sind einige der neuen Android 4-Funktionen in Android 2.3 nicht enthalten ImageView.setLayerType. Um Laufzeitfehler einfach zu vermeiden:

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

Dieser Ansatz sollte auch mit Ausnahmebehandlung verwendet werden:

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

NetworkOnMainThreadExceptionist in Android 2.3 nicht implementiert. Wenn die Klasse geladen wird (und nicht vorher!), tritt die Ausnahme java.lang.VerifyErrorauf.


1
Das gleiche passierte mit mir. Ich habe verwendet, java.lang.ReflectiveOperationExceptionwas nicht in älteren Android-Versionen enthalten ist (zum Beispiel 4.2), aber Lint hat mich nicht davor gewarnt ...
WonderCsabo

Für mich ist das Problem, dass mein Code a deklariert CameraAccessException, der unter Android 5.0 eingeführt wird. Wenn ich jedoch auf einem Android 4.3-Gerät ausgeführt werde, wird der VerifyError ausgelöst.
Piasy

7

Wenn Sie Retrolambda verwenden, haben Sie möglicherweise einer Schnittstelle eine statische Methode hinzugefügt (die nur in Java 8 zulässig ist).


7

Dies kann auch aufgrund eines Referenzierungslimitfehlers bei Lollypop unterhalb der Versionen auftreten, bei dem die Größe auf maximal 65 KB begrenzt ist

Mögliche Lösung für das oben genannte Problem

Schritt 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

Schritt 2: Erweitern Sie Ihre Anwendung mit MultiDexApplication, z

public class MyApplication extends MultiDexApplication

Schritt 3: Überschreiben Sie attachBaseContext

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

Schritt 4: Der nächste Schritt besteht darin, dem Android-Teil Ihrer Apps build.gradle Folgendes hinzuzufügen

 dexOptions {
      preDexLibraries = false
   }

Schritt 5: Befolgen Sie zum Schluss den allgemeinen Teil Ihrer Apps build.gradle

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

Für Details bitte auschecken

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


Hat für mich gearbeitet !! Vergessen Sie nicht, die Anwendungsklasse in "MultiDexApplication" zu ändern.
Ganesh

Du hast mich gerettet, Mann. Dies sollte die akzeptierte Antwort sein.
Rohit Rokde

3

In meinem Fall passierte es, als ich von Eclipse Indigo auf Eclipse Juno aktualisierte: Ich bin nicht sicher, was der wahre Grund ist, aber mein Android-Projekt, an dem ich lange arbeite, hat aufgrund dieser Ausnahme die Arbeit eingestellt.

Nachdem ich viele Stunden lang versucht hatte, das zu beheben, fand ich die Lösung für mich.

In meinem Android-Projekt verwende ich ein anderes Projekt (z. B. "MyUtils"), das sich im selben Arbeitsbereich befindet. Also musste ich Folgendes tun:

Klicken Sie mit der rechten Maustaste auf Android-Projekt -> Erstellungspfad -> Erstellungspfad konfigurieren

Gehen Sie nun zur Registerkarte "Bestellen und Exportieren" und aktivieren Sie "MyUtils". Das war's: Ich habe diese nervige Ausnahme beseitigt.


Das hat es für mich behoben ... wir haben ein großes Projekt, also bin ich herumgegangen und habe einfach die "Export" -Flagge für alles überprüft. PITA-Problem.
Jemand irgendwo

3

Ich habe die Gradle-Version von 2.0.0-alpha2 auf 1.5.0 herabgestuft, um dieses Problem zu lösen.


2

Das Problem könnte auch durch eine Nichtübereinstimmung zwischen zwei Androidenprojekten verursacht werden. Wenn Sie beispielsweise eine Android-Bibliothek mit dem Paket "com.yourcompany" entwickelt haben, verwenden Sie das Projekt der Hauptanwendung mit demselben Paket wie das Basispaket. Angenommen, Sie möchten die Version Ihrer Hauptanwendung ändern, sodass Sie die Werte der Manifestdatei ändern: Versionscode und Versionsname. Wenn Sie Ihre App ausführen, ohne diese Werte für die Bibliothek zu ändern, wird bei jedem Aufruf einer Methode für ein Objekt aus der Bibliothek ein Überprüfungsfehler angezeigt.


2

Ich hatte das gleiche Problem. Ich habe mit 2.1 r1 gebaut und mit dem neuen adt 17 auf 2.1 r3 aktualisiert. Ich hatte Fehler in javamails mail.jar überprüft und es hat mich verrückt gemacht. So habe ich das Problem gelöst:

  1. hat einen libs / Ordner erstellt und die Gläser hinzugefügt.
  2. Rechtsklick> Als Quellordner hinzufügen

Ich habe einen Wiederaufbau versucht und es ist fehlgeschlagen. Ich habe das Verzeichnis libs / als Quellordner entfernt und Verweise auf die 3 JAR-Dateien im Erstellungspfad entfernt. Dann habe ich den Ordner libs / erneut hinzugefügt und jedes Glas im Ordner libs / zum Erstellungspfad hinzugefügt. Jetzt funktioniert es wie erwartet. Dies ist eine seltsame Problemumgehung, aber es hat bei mir funktioniert.


2

In Eclipse 4.x, wenn Sie dieses Problem auftritt, versuchen Sie unter:

  1. Migrieren Sie alle enthaltenen Gläser von Drittanbietern in die User-Libaray
  2. Verschieben Sie die Benutzerbibliothek vor die Android-Bibliothek und überprüfen Sie sie auf der Registerkarte Bestellen und Exportieren
  3. reinigen und neu aufbauen, um zu laufen

2

Ich habe dieses Problem nach einem SDK-Update. Der Compiler hatte Probleme mit meinen externen Bibliotheken. Ich habe dies getan: Klicken Sie mit der rechten Maustaste auf das Projekt und dann auf "Android Tools> Unterstützungsbibliothek hinzufügen ...". Diese Installation in meiner Projektbibliothek "android-support-v4.jar".


2

java.lang.VerifyErrorbedeutet, dass sich Ihr kompilierter Bytecode auf etwas bezieht, das Android zur Laufzeit nicht finden kann. Dieser verifyError gibt mir nur Probleme mit kitkat4.4 und einer kleineren Version, die nicht in der obigen Version enthalten ist , selbst wenn ich auf beiden Geräten denselben Build ausgeführt habe. als ich jackson json parser der älteren version verwendet habe, zeigt esjava.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.+'

Dann habe ich die Dependancy der geänderten neueste Version 2,2 bis 2,7 ohne die Kernbibliothek (wenn ich core2.7 enthalten gibt es die VerifyError), dann funktioniert es. Dies bedeutet, dass die Methoden und andere Inhalte des Kerns auf die neueste Version von Databind2.7 migriert werden . Dies behebt meine Probleme.

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

1

Ich bekomme auch den VerfiyError ... kann keinen wirklichen Grund finden. Es hilft, die neuen Codezeilen in eine Methode zu packen (Eclipse, 'Extract Method ...'). In meinem Fall ist der Grund also keine nicht unterstützte Methode.


1

Ich hatte ein sehr ähnliches Problem. Ich hatte Apache POI- Jars hinzugefügt und das Problem trat auf, als ich auf Android SDK 22.3 aktualisierte.

Ich hatte Android Private Libraries überprüft, so dass dies nicht das häufigste Problem mit Android SDK war. Ich habe alle Apache POI- Gläser deaktiviert und nacheinander hinzugefügt. Ich fand, dass poi-3.9-20121203.jar vor poi-ooxml-3.9-20121203.jar sein sollte . Sonst funktioniert es nicht.


1

Wenn Sie Tests haben, versuchen Sie, diese Zeile aus Ihrer build.gradeDatei zu kommentieren :

testCoverageEnabled = true

Für mich verursachte dies VerifyError-Ausnahmen für Klassen, die Java 1.7-Funktionen verwenden, insbesondere String-Switch-Anweisungen.


1

Ich hatte das gleiche Problem, nachdem ich einen Git Pull gezogen hatte.

Lösung: Erstellen -> Projekt bereinigen.

Hoffe das hilft.


1
Hat nicht wirklich gezogen oder irgendetwas getan, aber ein sauberer hat es getan, danke!
Alexandre G

1

Ich habe einen anderen Fall gefunden.

Bedingungen:

  • Verwenden Sie Retrolambda (nicht sicher, ob es notwendig ist);
  • Erstellen Sie eine statische Methode in einer Schnittstelle.

Und das Ergebnis ist ein Boom! java.lang.VerifyError beim Versuch, auf die Klasse zuzugreifen, die diese Schnittstelle verwendet. Es sieht so aus, als ob Android (in meinem Fall 4.4. *) Statische Methoden in Schnittstellen nicht mag. Durch Entfernen der statischen Methode von der Schnittstelle wird VerifyError gelöscht.


0

Ich hatte auch dieses Problem, ebenso wie meine Gläser in einer Benutzerbibliothek ...

Die Art und Weise, wie ich das gelöst habe, bestand darin, sie dem lib-Ordner hinzuzufügen und sie dann in den Build-Eigenschaften von Eclipse hinzuzufügen ...

Das erste Mal, als ich das tat, funktionierte es nicht, aber dann entfernte ich sie und las sie erneut und es fing an zu funktionieren ...

ein bisschen seltsam! aber jetzt die ganze Zeit arbeiten.

Viel Glück


0

Ich habe Android API-Methoden / -Klassen codiert, die in SDK 2.1 enthalten sind, und habe versucht, sie auf dem Android 1.6-Emulator auszuführen. Also habe ich diesen Fehler bekommen.

LÖSUNG: Es wurde geändert, um die Emulatorversion zu korrigieren.

Das hat für mich funktioniert . Danke.


0

Für die Nachwelt habe ich gerade diesen Fehler erhalten, weil ich Arrays.copyOf()eine von Java 1.5 unterstützte Methode verwendet habe, die Android Level 4 entspricht. Da ich Bibliotheken ausgeführt habe, die unter 1.6 entwickelt wurden, wurden sie gut kompiliert. Ich habe die Probleme erst gesehen, als ich die betreffende Klasse in mein Android-Projekt verschoben habe - dann wurde der Fehler hervorgehoben.

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)

In dieser Zeile habe ich versucht, eine zu machen, new DaoConfigArrayund diese Klasse hatte die folgende Zeile:

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

Was es noch komplizierter machte, war, dass Zeile 71 auf eine ThreadLocalInitialisierung hinwies, von der ich dachte, dass sie anfangs der Grund für das Problem war.

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

0

Ich musste abhängige Projekte entfernen und stattdessen abhängige Projekte kompilieren, die JARs sind, und sie in den libs-Ordner aufnehmen.


0

Ich bin mir sicher, dass meine Sache anders war als Ihre, aber da dies einer der Top-Hits bei der Suche nach "Android java.lang.VerifyError" ist, dachte ich, ich würde es hier für die Nachwelt aufnehmen.

Ich hatte einige Klassen in der Art von:

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

Und eine Methode, die Folgendes tat:

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

// Fill result
...

Solange dieser Code in der Datei vorhanden war, wurde beim ersten Laden der Klasse mit dieser Methode ein VerifyError angezeigt. Die Aufteilung in zwei separate Methoden (eine, die sich nur mit B befasste, und eine, die sich nur mit C befasste) behebt das Problem.


1
Übrigens war die Art und Weise, wie ich es verursacht habe, das Auskommentieren von Methodenkörpern (Ersetzen durch return null / 0 / false), bis der VerifyError verschwand, und das Wiederherstellen von Inhalten, bis er wieder zurückkam. dann machen Sie dasselbe innerhalb der Problemmethode. Sicherlich keine unterhaltsame Art zu debuggen, aber es hat funktioniert.
Benkc

0

In meinem Fall tritt dieser Fehler auf, weil mein Google-Play-Service nicht der neueste ist .

Wenn Ihr Projekt eine Klasse in der JAR-Datei nicht unterstützt, tritt dieser Fehler auf (z. B. ImageView.setLayerType, AdvertisingIdClient usw.).


0

Ich habe gerade eine andere Situation identifiziert, die auftritt, nicht nur aufgrund von Bibliotheken, die nicht bearbeitet wurden . Ich habe eine AsyncTask mit einem sehr langen doInBackground-Modus. Aus irgendeinem Grund begann diese Methode mit mehr als 145 Zeilen zu brechen. Es passierte auf einer 2.3 App. Als ich nur einige Teile in Methoden eingekapselt habe, hat es gut funktioniert.

Also für diejenigen , die nicht die Klasse finden konnten , die nicht korrekt war dx ‚ed, versuchen Sie die Länge Ihrer Methode zu reduzieren.


0

Für mich bestand das Problem darin, dass ich irgendwo in der Klasse eine Multi-Catch-Klausel verwendete, bei der es sich um eine Java 7-Funktion (und API 19+) handelt. Es würde also VerifyErrorauf allen Geräten vor 19 Jahren abstürzen .


0

Für mich war es eine Korrelation zwischen compileSdkVersion und buildToolsVersion. Ich hatte:

compileSdkVersion 21
buildToolsVersion '19.1.0'

Ich habe es geändert in:

compileSdkVersion 21
buildToolsVersion '21.1.2'

0

Für mich ist es das Problem von compileSdkVersion. Als ich die API-Stufe 21 in einer bestimmten Android-Anwendung verwendet habe ( https://github.com/android10/Android-AOPExample ):

compileSdkVersion 21

Der Fehler java.lang.verifyerror ist aufgetreten. Also habe ich die compileSdkVersion auf 19 geändert

compileSdkVersion 19

Es hat gut funktioniert. Ich denke, dass es das Problem von SDK buildTools sein könnte, und es scheint in Ordnung zu sein, wenn API-Level <21.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.