Android java.lang.VerifyError?

Dans mon application Android, j'obtiens toujours VerifyErrors! Et je ne peux pas comprendre pourquoi. Chaque fois que j'inclus un JAR externe, j'obtiens toujours VerifyErrors lorsque j'essaie de lancer mon application (sauf pour une fois, lorsque j'ai inclus Apache Log4j.)

J'ai l'habitude de contourner ce problème en prenant la source de la bibliothèque et en l'ajoutant à mon projet, mais j'essaye de mettre la bibliothèque cliente GData .

Je peux obtenir cela dans la source, mais ce sont des dépendances (mail.jar, activation.jar, servlet-api.jar) Je ne peux pas, donc j'obtiens des erreurs de vérification. Je voudrais aller une fois pour toutes à la racine de ce problème. J'ai regardé sur Internet, mais ils semblent tous parler de fichiers de classe incomplets? dont je ne sais pas.

Android utilise un format de fichier de classe différent. Exécutez-vous les fichiers JAR tiers via l'outil «dx» fourni avec le SDK Android?

Regardez LogCat et voyez ce qui cause l'erreur de vérification. Il s'agit probablement d'une méthode dans une classe java.lang qui n'est pas prise en charge au niveau du SDK Android que vous utilisez (par exemple, String.isEmpty ()).

Des développeurs Android :

La sortie de "adb logcat" indique la classe qui n'a pas pu être trouvée ainsi que la classe qui a la mauvaise référence. L'emplacement est identifié jusqu'à l'instruction spécifique de Dalvik. L'astuce consiste à regarder dans les journaux au-dessus de l'exception.

Pour que cela fonctionne, vous devez ajouter le fichier jar de la bibliothèque à l'un des dossiers source (même si vous l'avez déjà ajouté en tant que bibliothèque eclipse, vous devez toujours l'ajouter en tant que source).

1. Créez un répertoire dans votre projet (ex "libs") et mettez-y la bibliothèque jar.
2. Ajoutez le répertoire au chemin de la classe de construction en (cliquez sur le bouton droit sur le dossier et sélectionnez "Chemin de construction" -> "Utiliser comme dossier source").
3. Reconstruisez votre projet.

Cela m'est arrivé maintenant. L'erreur a été causée car j'utilisais des méthodes d'un SDK plus récent que mon appareil avait.

L'appareil Android 1.5 a installé un apk en utilisant ceci:

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

J'ai trouvé un cas intéressant. J'utilise:

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

Ainsi, certaines des nouvelles fonctionnalités d'Android 4 ne sont pas implémentées dans Android 2.3 comme ImageView.setLayerType. Pour éviter les erreurs d'exécution simplement:

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

Cette approche doit également être utilisée avec la gestion des exceptions:

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

NetworkOnMainThreadExceptionn'est pas implémenté dans Android 2.3 donc lorsque la classe est chargée (et pas avant!), l'exception java.lang.VerifyErrorse produit.

Si vous utilisez Retrolambda, vous avez peut-être ajouté une méthode statique à une interface (qui n'est autorisée que dans Java 8).

Cela peut également se produire en raison d'une erreur de limite de référencement sur les versions Lollypop ci-dessous, où il est limité jusqu'à une taille maximale de 65K

Solution possible pour le problème ci-dessus

Étape 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

Étape 2: étendez votre application avec MultiDexApplication, par exemple

public class MyApplication extends MultiDexApplication

Étape 3: remplacer attachBaseContext

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

Étape 4: l'étape suivante consiste à ajouter ce qui suit à la partie Android de vos applications build.gradle

 dexOptions {
      preDexLibraries = false
   }

Étape 5: Enfin, en suivant la partie générale de vos applications build.gradle

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

Pour plus de détails, veuillez vérifier

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

Dans mon cas, cela s'est produit lorsque j'ai mis à jour Eclipse Indigo vers Eclipse Juno: je ne sais pas quelle est la vraie raison, mais mon projet Android sur lequel je travaille depuis longtemps a cessé de fonctionner à cause de cette exception.

Après plusieurs heures à essayer de résoudre ce problème, j'ai trouvé la solution pour moi.

Dans mon projet Android, j'utilise un autre projet (par exemple, "MyUtils") qui se trouve dans le même espace de travail. Donc, j'avais besoin de faire ce qui suit:

Faites un clic droit sur le projet Android -> Chemin de construction -> Configurer le chemin de construction

Maintenant, allez dans l'onglet "Order and Export" et cochez "MyUtils". Voilà: je me suis débarrassé de cette exception ennuyeuse.

Je rétrograde la version gradle de 2.0.0-alpha2 à 1.5.0 qui a résolu ce problème.

Le problème pourrait également être causé par un décalage entre deux projets androïdes. Par exemple, si vous avez développé une bibliothèque Android en utilisant le package "com.yourcompany", alors vous avez le projet de l'application principale utilisant le même package que le package de base. Supposons ensuite que vous souhaitiez modifier la version de votre application principale, afin de modifier les valeurs du fichier manifeste: code de version et nom de version. Si vous exécutez votre application sans modifier ces valeurs pour la bibliothèque, vous obtiendrez une erreur de vérification lors de tout appel d'une méthode sur un objet de la bibliothèque.

J'ai eu le même problème. Je construisais avec 2.1 r1 et mis à jour à 2.1 r3 avec le nouvel adt 17. J'avais vérifié des erreurs sur le mail.jar de javamail et cela me rendait fou. Voici comment j'ai résolu le problème:

1. créé un dossier libs / et ajouté les jars.
2. clic droit> ajouter comme dossier source

J'ai essayé une reconstruction et cela a échoué. J'ai supprimé le répertoire libs / en tant que dossier source et supprimé les références aux 3 fichiers jar dans le chemin de construction. Ensuite, j'ai à nouveau ajouté le dossier libs / et ajouté chaque jar dans le dossier libs / au chemin de construction. Maintenant, cela fonctionne comme prévu. C'est une solution de contournement étrange mais cela a fonctionné pour moi.

Dans Eclipse 4.x, si vous rencontrez ce problème, essayez ci-dessous:

1. migrer tous les jars tiers inclus dans User-Libaray
2. déplacez la bibliothèque utilisateur avant la bibliothèque android et vérifiez-la dans l'onglet Commande et exportation
3. nettoyer et reconstruire pour fonctionner

J'ai ce problème après une mise à jour du SDK. Le compilateur a eu des problèmes avec mes bibliothèques externes. J'ai fait ceci: clic droit sur le projet, puis "Outils android> ajouter une bibliothèque suport ..." cette installation sur ma bibliothèque de projet "android-support-v4.jar".

java.lang.VerifyErrorsignifie que votre bytecode compilé fait référence à quelque chose qu'Android ne peut pas trouver au moment de l'exécution. Cette verifyError ne me pose que kitkat4.4 et la version inférieure pas dans la version ci-dessus, même si j'ai exécuté la même version dans les deux appareils. quand j'ai utilisé l'analyseur jackson json d'une ancienne version, cela se voitjava.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.+'

Ensuite, j'ai changé la dépendance à la dernière version 2.2 à 2.7 sans la bibliothèque de base (lorsque j'inclus core2.7, cela donne le verifyError), alors cela fonctionne. ce qui signifie que les méthodes et autres contenus de core sont migrés vers la dernière version de Databind2.7 . Cela corrige mes problèmes.

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

Je reçois également VerfiyError ... je ne trouve pas de vraie raison. Cela aide à envelopper les nouvelles lignes de code dans une méthode (Eclipse, 'Extract Method ...'). Donc, dans mon cas, la raison n'est pas une méthode non prise en charge.

J'ai eu un problème très similaire. J'avais ajouté Apache POI jars et un problème est apparu lors de la mise à jour vers Android SDK 22.3.

J'ai fait vérifier les bibliothèques privées Android, donc ce n'était pas le problème courant avec le SDK Android. J'ai décoché tous les jars Apache POI et les ai ajoutés un par un. J'ai trouvé que poi-3.9-20121203.jar devrait être avant poi-ooxml-3.9-20121203.jar . Sinon, cela ne fonctionnera pas.

Si vous avez des tests, essayez de commenter cette ligne de votre build.gradefichier:

testCoverageEnabled = true

Pour moi, cela a provoqué des exceptions VerifyError sur les classes qui utilisent les fonctionnalités de Java 1.7, en particulier les instructions de commutation de chaîne.

J'ai eu le même problème après avoir fait un git pull.

Solution: Construire -> Nettoyer le projet.

J'espère que cela t'aides.

J'ai trouvé un autre cas.

Conditions:

• Utilisez Retrolambda (je ne sais pas si c'est nécessaire);
• Créez une méthode statique dans une interface.

Et le résultat est boom! java.lang.VerifyError lors de la tentative d'accès à la classe qui utilise cette interface. On dirait qu'Android (4.4. * Dans mon cas) n'aime pas les méthodes statiques dans les interfaces. La suppression de la méthode statique de l'interface fait disparaître VerifyError.

J'ai aussi eu ce problème, tout comme mes pots dans une bibliothèque utilisateur ...

La façon dont j'ai résolu ce problème était de les ajouter au dossier lib, puis de les ajouter dans les propriétés de construction dans eclipse ...

La première fois que j'ai fait cela, cela n'a pas fonctionné, mais ensuite je les ai supprimés et les ai relus à nouveau et cela a commencé à fonctionner ...

un peu étrange! mais travaille maintenant tout le temps.

Bonne chance

J'ai codé des méthodes / classes d'API Android qui se trouvent dans le SDK 2.1 et j'essayais de l'exécuter sur l'émulateur Android 1.6. Alors j'ai eu cette erreur.

SOLUTION: l'a changé pour corriger la version de l'émulateur.

CELA A FONCTIONNÉ POUR MOI .. Merci.

Pour la postérité, je viens de recevoir cette erreur parce que j'utilisais Arrays.copyOf()une méthode qui n'est pas prise en charge par Java 1.5 qui correspond au niveau Android 4. Parce que j'utilisais des bibliothèques développées sous 1.6, elles se sont bien compilées. Je n'ai vu les problèmes que lorsque j'ai déplacé la classe en question vers mon projet Android - alors l'erreur a été mise en évidence.

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)

Sur cette ligne, j'essayais de faire un new DaoConfigArrayet cette classe avait la ligne suivante:

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

Ce qui a rendu les choses encore plus compliquées, c'est que la ligne 71 indiquait une ThreadLocalinitialisation que je pensais être la raison du problème au départ.

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

J'ai dû supprimer les projets dépendants et à la place, compiler les projets dépendants sont des jar et les inclure dans le dossier libs.

Je suis sûr que ma cause était différente de la vôtre, mais comme c'est l'un des meilleurs résultats lors de la recherche de "Android java.lang.VerifyError", j'ai pensé l'enregistrer ici pour la postérité.

J'ai eu quelques cours du genre:

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

Et une méthode qui a fait:

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

// Fill result
...

Tant que ce code était présent dans le fichier, j'obtiendrais un VerifyError la première fois que la classe contenant cette méthode était chargée. Le diviser en deux méthodes distinctes (une qui ne traitait que des B et une qui ne traitait que des C) résolvait le problème.

Dans mon cas, cette erreur se produit car mon service google-play n'est pas le plus récent .

Si votre projet ne prend pas en charge une classe dans le .jar, cette erreur se produit (par exemple ImageView.setLayerType, AdvertisingIdClient, etc.).

Je viens d'identifier une autre situation où cela se produit, non seulement en raison de libs et non de dx 'ed. J'ai une AsyncTask avec un très long mehtod doInBackground. Pour une raison quelconque, cette méthode avec plus de 145 lignes a commencé à se rompre. C'est arrivé sur une application 2.3. Lorsque je viens d'encapsuler certaines parties dans des méthodes, cela a bien fonctionné.

Donc pour ceux qui n'ont pas pu trouver la classe qui n'était pas correctement dx , essayez de réduire la longueur de votre méthode.

Pour moi, le problème a finalement été que j'utilisais une clause multi-catch quelque part dans la classe qui est une fonctionnalité Java 7 (et API 19+). Donc, il planterait VerifyErrorsur tous les appareils pré-19.

Pour moi, c'était en corrélation entre compileSdkVersion et buildToolsVersion. J'ai eu:

compileSdkVersion 21
buildToolsVersion '19.1.0'

Je l'ai changé en:

compileSdkVersion 21
buildToolsVersion '21.1.2'

Pour moi, c'est le problème de compileSdkVersion. Lorsque j'ai utilisé le niveau API 21 dans une application Android spécifique ( https://github.com/android10/Android-AOPExample ):

compileSdkVersion 21

l'erreur java.lang.verifyerror s'est produite. J'ai donc changé la version compileSdkVersion en 19

compileSdkVersion 19

Cela a bien fonctionné. Je pense que cela pourrait être le problème de SDK buildTools, et cela semble correct lorsque le niveau d'API <21.