Android java.lang.VerifyError?


100

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.


GData est connu pour ne pas fonctionner sous Android. Recherchez le sujet dans le groupe Google des développeurs Android. Nous devons attendre une GData officielle pour Android, dans une future version du SDK.
mparaz

1
Utilisez-vous Gradle pour créer votre projet? J'ai eu ce problème quand j'ai oublié d'exécuter la tâche de nettoyage avant la tâche d'assembleRelease ...
IgorGanapolsky

Réponses:


35

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?


4
Ce serait génial avec quelques informations supplémentaires sur l'outil "dx".
Daniel Magnusson

2
Regardez dans la section "Bibliothèque" des préférences du projet Android, sous la liste des versions du SDK. Vos projets externes sur lesquels vous comptez dans votre build apparaissent-ils là-haut, avec une coche verte à côté d'eux?
Adam

@Adam MERCI pour ce commentaire! Vous venez de résoudre un problème que j'ai passé beaucoup trop de temps à essayer de comprendre.
Simon Forsberg

118

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


4
Cela devrait être marqué comme une vraie réponse. Au moins ce que c'était exactement dans mon cas puisque je recevais des erreurs sporadiques de la part de mes utilisateurs et que je l'ai suivi jusqu'à l'appel View.getTag (int) qui n'est pas pris en charge dans la version 3 de l'API
Bostone

1
D'accord. J'ai rencontré cela plusieurs fois et à chaque fois, c'est que je cible la 2.x et que j'utilise quelque chose qui n'est pas en 1.5. Ce qui vous dérange, c'est qu'elle est lancée lorsque la classe est créée / utilisée pour la première fois uniquement, donc si c'est quelque chose qui se produit sporadiquement, vous risquez de ne pas le remarquer pendant un certain temps.
mbafford


"Cela devrait être marqué comme une vraie réponse." Je suis tombé sur ce fil parce que j'ai le même problème. Je suppose que la raison pour laquelle cela n'a pas été marqué comme la vraie réponse est que LogCat donne une référence de ligne à l'endroit où je crée une instance d'une bibliothèque mais pas à la ligne où le problème est causé. En d'autres termes, dans ce cas, LogCat est presque inutile.
NotACleverMan

logcat au niveau WARN devrait vous montrer les détails de la raison pour laquelle la vérification a échoué
mmeyer

56

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.


6
Regarder au-dessus de l'exception m'a également aidé à identifier la méthode à l'origine de l'erreur. Pour moi, c'était l'expression Build.VERSION.SDK_INT> = Build.VERSION_CODES.ECLAIR qui est un peu évidente, au final, si vous essayez ça sur Cupcake ...
Manuel

2
Merci! C'était le problème que j'obtenais ... les journaux utiles étaient juste au-dessus de l'exception: WARN/dalvikvm(1052): VFY: unable to resolve static method 475: Ljavax/xml/datatype/DatatypeFactory;.newInstance ()Ljavax/xml/datatype/DatatypeFactory;(maintenant pour savoir comment faire sans DatatypeFactory)
pyko

Regarder au-dessus de l'erreur m'a également aidé. Recherchez un message qui commence par "VFY:" Dans mon cas, il a dit "rejet arbitraire de la grande méthode". Probablement parce qu'il crée un grand nombre de tableaux :) de toute façon, merci pour le conseil!
Amplify91

Merci! J'ai trouvé que mon problème concernait le gestionnaire d'exceptions: NetworkOnMainThreadException n'est pas implémenté dans Android 2.3. Cherchez ma réponse. Merci encore! :)
Seraphim's

Merci! Dans mon cas, je ciblais Android2.3 et j'utilisais android-support-v4.jar, et je ne trouvais pas les classes dans ce fichier. J'ai dû cliquer sur l'onglet "exporter" pour cette classe dans les propriétés et l'amener au-dessus de la bibliothèque android2.3.3. Eh bien, cette exportation est vraiment quelque chose que je ne comprends pas clairement ...
xtof54

14

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.

Pouvons-nous ajouter une "Bibliothèque de projet" au lieu d'un JAR dans le dossier 'libs'?
Ahmed

Étrange ... J'ai dû l'ajouter en tant que bibliothèque Java normale - pas en tant que bibliothèque sous le menu "Android" dans Eclipse.
Phil

Merci Maksim, belle solution.
Arun Badole

8

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

8

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.


1
La même chose s'est produite avec moi. J'ai utilisé java.lang.ReflectiveOperationExceptionce qui n'est pas inclus dans les anciennes versions d'Android (par exemple 4.2), mais Lint ne m'a pas prévenu à ce sujet ...
WonderCsabo

Pour moi, le problème est que mon code déclare a CameraAccessException, qui est introduit dans Android 5.0, mais lorsque je l'exécute sur un appareil Android 4.3, VerifyError est levé.
Piasy

7

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


7

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


A travaillé pour moi !! n'oubliez pas de changer la classe Application en "MultiDexApplication".
Ganesh

Tu m'as sauvé beaucoup de temps. Cela devrait être la réponse acceptée.
Rohit Rokde

3

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.


C'est ce qui a résolu le problème pour moi ... nous avons un gros projet alors je suis allé et j'ai vérifié le drapeau "export" sur tout. Problème PITA.
Someone Somewhere

3

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


2

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.


2

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.


2

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

2

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


2

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'

1

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.


1

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.


1

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.


1

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.


1
Je n'ai pas tiré ou fait quoi que ce soit vraiment, mais un nettoyage l'a fait, merci!
Alexandre G

1

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.


0

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


0

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.


0

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

0

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.


0

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.


1
Et, en passant, la façon dont je l'ai causé par la racine a été de commenter les corps de méthode (en remplaçant par return null / 0 / false) jusqu'à ce que VerifyError disparaisse, puis en restaurant des éléments jusqu'à ce qu'ils reviennent; puis faire de même dans la méthode du problème. Pas une manière amusante de déboguer, certes, mais cela a fonctionné.
benkc

0

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


0

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.


0

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.


0

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'

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.