Android Java.lang.VerifyError?
Dans mon Android, je reçois toujours VerifyErrors! Et je ne peux pas comprendre pourquoi. Chaque fois que j'inclus un fichier JAR externe, je reçois toujours VerifyErrors lorsque j'essaie de lancer mon application (sauf une fois, lorsque J'ai inclus Apache Log4j.)
Je contourne généralement cela en prenant le source de la bibliothèque et en l'ajoutant à mon projet, mais j'essaie de mettre le bibliothèque du client GData .
Je peux obtenir cela dans le source, mais ce sont des dépendances (mail.jar, activation.jar, servlet-api.jar) que je ne peux pas, je reçois donc des erreurs de vérification. Je voudrais aller à la racine de ce problème une fois pour toutes. J'ai regardé sur Internet, mais ils semblent tous parler de fichiers de classe incomplets? que je ne connais 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 Android SDK?)?
Regardez LogCat et voyez ce qui cause l'erreur de vérification. Il s'agit probablement d'une méthode d'une classe Java.lang qui n'est pas prise en charge sur le niveau de SDK Android que vous utilisez (par exemple, String.isEmpty ()).
De développeurs Android :
La sortie de "adb logcat" indique la classe introuvable ainsi que la classe contenant la mauvaise référence. L'emplacement est identifié par l'instruction spécifique 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).
- Créez un répertoire dans votre projet ("libs", par exemple) et placez-y la bibliothèque jar.
- Ajoutez le répertoire au chemin de classe de construction en cliquant sur (cliquez avec le bouton droit de la souris sur le dossier et sélectionnez "Chemin de construction" -> "Utiliser comme dossier source").
- Reconstruisez votre projet.
J'ai trouvé un cas intéressant. J'utilise:
<uses-sdk
Android:minSdkVersion="9"
Android:targetSdkVersion="18" />
Ainsi, certaines des nouvelles capacités Android 4 ne sont pas implémentées dans Android 2.3 comme ImageView.setLayerType. Pour éviter les erreurs d’exécution, il suffit de:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
setLayerType(View.LAYER_TYPE_SOFTWARE, null);
}
Cette approche devrait également être utilisée avec des exceptions:
} catch (NetworkOnMainThreadException nomte) {
// log this exception
} catch (SocketTimeoutException socketTimeoutException) {
// log this exception
}
NetworkOnMainThreadException n'est pas implémenté dans Android 2.3 alors quand la classe est chargée (et pas avant!) l'exception Java.lang.VerifyError se produit.
Cela m'est arrivé maintenant. L'erreur était due au fait que j'utilisais des méthodes d'un SDK plus récent installé sur mon appareil.
Android 1.5 device a installé un apk en utilisant ceci:
<uses-sdk Android:minSdkVersion="3" Android:targetSdkVersion="4"/>
Si vous utilisez Retrolambda, vous avez peut-être ajouté une méthode statique à une interface (autorisée uniquement dans Java 8).
Cela peut également se produire en raison d'une erreur de limitation du référencement sur les versions inférieures de Lollypop, où sa taille est limitée à une taille maximale de 65 Ko.
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: La prochaine étape consiste à ajouter les éléments suivants à la partie Android de votre application build.gradle
dexOptions {
preDexLibraries = false
}
Étape 5: Enfin, suivez la partie générale de votre application 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 commander
Je rétrograde la version 2.0.0-alpha2 de la version 2.0 à la version 1.5.0 qui a résolu ce problème.
Dans mon cas, cela m'est arrivé lorsque j'ai mis à jour Eclipse Indigo vers Eclipse Juno: je ne sais pas quelle est la vraie raison, mais mon Android sur lequel je travaille longuement) le temps s'est arrêté de travailler à cause de cette exception.
Après beaucoup heures d'essayer de résoudre ce problème, j'ai trouvé la solution pour moi.
Dans mon Android, j'utilise un autre projet (par exemple, "MyUtils") qui se trouve dans le même espace de travail. J'ai donc dû procéder comme suit:
Faites un clic droit sur Android projet -> Chemin de construction -> Configurer le chemin de construction
Maintenant, allez dans l'onglet "Commander et exporter" et cochez "MyUtils". Ça y est: je me suis débarrassé de cette exception agaçante.
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: faites un clic droit sur le projet, puis "Outils Android> ajouter une bibliothèque suport ..." et installez-le dans la bibliothèque de projet "Android-support-v4.jar".
Dans Eclipse 4.x, si vous rencontrez ce problème, essayez ci-dessous:
- migrer tous les bocaux tiers inclus dans User-Libaray
- déplacez l'utilisateur lib avant le Android lib et vérifiez-le dans l'onglet Order and Export
- nettoyer et reconstruire pour fonctionner
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 des erreurs de vérification sur mail.jar de javamail et cela me rendait fou. Voici comment j'ai résolu le problème:
- créé un dossier libs/et ajouté les bocaux.
- clic droit> ajouter en tant que 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 dans les 3 fichiers jar du chemin de construction. Ensuite, j'ai ajouté le dossier libs/à nouveau, et ajouté chaque fichier jar dans le dossier libs/au chemin de construction. Maintenant, cela fonctionne comme prévu. C'est une solution bizarre mais cela a fonctionné pour moi.
Le problème pourrait également être causé par une inadéquation entre deux projets androïdes. Par exemple, si vous avez développé une bibliothèque Android à l'aide du package "com.votreentreprise"), le projet de l'application principale utilise alors le même package que le package de base. version de votre application principale, vous devez donc 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 bibliothèque.
J'ai aussi le VerfiyError ... je ne peux pas trouver une vraie raison. Il est utile d’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 le même problème après avoir tiré un git.
Solution: Construire -> Nettoyer le projet.
J'espère que cela t'aides.
J'ai eu un problème très similaire. J'avais ajouté bocaux Apache et le problème est apparu lors de la mise à jour vers Android SDK 22.3.
J'avais Android Bibliothèques privées coché, donc ce n'était pas le problème commun avec Android SDK. J'ai décoché tous les Apache POI bocaux et j'ai ajouté 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.
J'ai trouvé un autre cas.
Conditions:
- Utilisez Retrolambda (ne savez pas si c'est nécessaire);
- Crée une méthode statique dans une interface.
Et le résultat est boum! Java.lang.VerifyError lors d'une tentative d'accès à la classe qui utilise cette interface. On dirait que Android (4.4. * Dans mon cas)) n'aime pas les méthodes statiques dans les interfaces. Si vous supprimez la méthode statique de l'interface, VerifyError disparaît.
Java.lang.VerifyError _ signifie que votre bytecode compilé fait référence à quelque chose que Android ne peut pas trouver au moment de l’exécution. Cette verifyError ne m’émet que avec KitKat4.4 et une version inférieure non mentionnée ci-dessus. version de cela même si j’ai eu la même version dans les deux appareils. Quand j’ai utilisé l’analyseur jackson json de l’ancienne version, il montre Java.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 en 2.7 sans la bibliothèque principale (quand j'inclus core2.7 cela donne le verifyError), alors ça marche. ce qui signifie que les méthodes et autres contenus de noyau 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'
Si vous avez des tests, essayez de commenter cette ligne à partir de votre fichier build.grade:
testCoverageEnabled = true
Pour moi, cela a provoqué des exceptions VerifyError sur les classes qui utilisent les fonctionnalités Java 1.7, en particulier les instructions de commutateur de chaîne.
Je devais supprimer des projets dépendants et compiler à la place les projets dépendants, puis les inclure dans le dossier libs.
Pour moi, c'était en corrélation entre compileSdkVersion et buildToolsVersion. J'ai eu:
compileSdkVersion 21
buildToolsVersion '19.1.0'
Je l'ai changé pour:
compileSdkVersion 21
buildToolsVersion '21.1.2'
Dans mon cas, cette erreur est due au fait que mon google-play-service n’est pas le plus récent.
Si votre projet ne prend pas en charge une classe dans le fichier .jar, cette erreur se produit (par exemple, ImageView.setLayerType, AdvertisingIdClient, etc.).
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+). Il se planterait donc avec VerifyError sur tous les appareils antérieurs à 19 ans.
J'ai également 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 aux propriétés de construction dans Eclipse ...
La première fois que j'ai fait ça, ça ne marchait pas, mais ensuite je les ai enlevés et remis à nouveau et ça a commencé à marcher ...
peu étrange! mais travaille maintenant tout le temps.
Bonne chance
J'ai codé Android des méthodes/classes d'API qui se trouvent dans le SDK 2.1 et que j'essayais de l'exécuter sur l'émulateur Android 1.6. J'ai donc eu cette erreur.
SOLUTION: Modifié pour corriger la version de l'émulateur.
CECI A TRAVAILLÉ POUR MOI .. Merci.
Je viens d’identifier une autre situation dans laquelle elle se produit, pas seulement à cause des bibliothèques non dx 'ed. J'ai un AsyncTask avec un très long meInt de fond. Pour une raison quelconque, cette méthode avec plus de 145 lignes a commencé à casser. C'est arrivé sur une application 2.3. Quand j'ai simplement encapsulé certaines parties dans des méthodes, cela a bien fonctionné.
Donc, pour ceux qui ne pourraient pas trouver la classe qui n'était pas correctement dx 'ed, essayez de réduire la longueur de votre méthode.
Je suis sûr que ma cause était différente de la vôtre, mais comme c'est l'un des grands succès de la recherche sur "Android Java.lang.VerifyError", j'ai pensé l'enregistrer ici pour la postérité.
J'ai eu des 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 fractionnement en deux méthodes distinctes (une qui ne traitait que de B et l'autre qui ne traitait que de C) résolvait le problème.
Pour moi, c'est le problème de compileSdkVersion. Lorsque j'ai utilisé le niveau 21 de l'API dans une application spécifique Android ( https://github.com/Android10/Android-AOPExample )):
compileSdkVersion 21
l'erreur Java.lang.verify s'est produite. J'ai donc changé compileSdkVersion en 19
compileSdkVersion 19
Cela a bien fonctionné Je pense que cela pourrait être le problème de SDK buildTools, et cela semble OK lorsque le niveau de l’API <21.
Pour la postérité, je viens de recevoir cette erreur car j’utilisais Arrays.copyOf(), méthode non prise en charge par Java 1.5, ce qui correspond à Android Niveau 4. Comme je compilais bien les bibliothèques développées sous la 1.6, je ne voyais les problèmes que lorsque je transférais la classe en question vers mon projet Android - l’erreur était alors surlignée.
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 DaoConfigArray et cette classe avait la ligne suivante:
// copyOf is only supported in Java >= 1.6
doArray = Arrays.copyOf(daoArray, newLength);
Ce qui compliquait encore plus les choses, c’était que la ligne 71 indiquait une initialisation de ThreadLocal dont j’imaginais que c’était la raison du problème au départ.
private static final ThreadLocal<DaoConfigArray> daoConfigLevelLocal
= new ThreadLocal<DaoConfigArray>() {
@Override
protected DaoConfigArray initialValue() {
return new DaoConfigArray();
}
};