Android java.lang.VerifyError?

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

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

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

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.

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.

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"/>

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.

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

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

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.

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

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.

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.

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

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

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'

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.

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.

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.

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

Lösung: Erstellen -> Projekt bereinigen.

Hoffe das hilft.

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.

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

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.

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();
    }
};

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

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.

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

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.

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 .

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'

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.