Android java.lang.VerifyError?


100

Nella mia app Android ottengo sempre VerifyErrors! E non riesco a capire perché. Ogni volta che includo un JAR esterno, ottengo sempre VerifyErrors quando provo ad avviare la mia app (tranne una volta, quando ho incluso Apache Log4j.)

Di solito aggiro questo problema prendendo il sorgente della libreria e aggiungendolo al mio progetto, ma sto provando a mettere la libreria client GData .

Posso ottenerlo nella sorgente, ma sono le dipendenze (mail.jar, activation.jar, servlet-api.jar) non posso, quindi ottengo errori di verifica. Vorrei arrivare alla radice di questo problema una volta per tutte. Ho cercato su Internet, ma sembrano tutti parlare di file di classe incompleti? che non conosco.


È noto che GData non funziona su Android. Cerca l'argomento nel gruppo Google di sviluppatori Android. Dobbiamo attendere un GData ufficiale per Android, in una futura versione dell'SDK.
mparaz

1
Stai usando Gradle per costruire il tuo progetto? Ho avuto questo problema quando ho dimenticato di eseguire l'attività pulita prima di assemblareRelease task ...
IgorGanapolsky

Risposte:


35

Android utilizza un formato di file di classe diverso. Stai eseguendo i file JAR di terze parti tramite lo strumento "dx" fornito con Android SDK?


4
Sarebbe fantastico con qualche informazione in più sullo strumento "dx".
Daniel Magnusson

2
Cerca nella sezione "Libreria" delle preferenze del progetto Android, sotto l'elenco delle versioni dell'SDK. I tuoi progetti esterni su cui fai affidamento nella tua build si presentano lì, con un segno di spunta verde accanto a loro?
Adam,

@Adam GRAZIE per quel commento! Hai appena risolto un problema che ho passato troppo tempo a cercare di capire.
Simon Forsberg

118

Guarda LogCat e vedi cosa sta causando l'errore di verifica. Probabilmente è un metodo in una classe java.lang che non è supportato a livello di Android SDK che stai utilizzando (ad esempio, String.isEmpty ()).


4
Questo dovrebbe essere contrassegnato come risposta reale. Almeno quello che era esattamente nel mio caso poiché stavo ricevendo errori sporadici dai miei utenti e l'ho rintracciato alla chiamata View.getTag (int) che non è supportata nella v. 3 dell'API
Bostone

1
Concordato. L'ho riscontrato un paio di volte e ogni volta è che sto prendendo di mira 2.x e utilizzo qualcosa che non è in 1.5. Ciò che ti sconcerta è che viene lanciato solo quando la classe viene creata / utilizzata per la prima volta, quindi se è qualcosa che accade sporadicamente potresti non notarlo per un po '.
mbafford


"Questa dovrebbe essere contrassegnata come risposta reale." Mi sono imbattuto in questo thread perché ho lo stesso problema. Immagino che il motivo per cui questo non è stato contrassegnato come la vera risposta è perché LogCat fornisce un riferimento alla riga dove sto facendo un'istanza di una libreria ma non la riga in cui è causato il problema. In altre parole, in questo caso LogCat è quasi inutile.
NotACleverMan

logcat a livello WARN dovrebbe mostrarti i dettagli sul motivo per cui non è riuscita a verificare
mmeyer

56

Dagli sviluppatori Android :

L'output di "adb logcat" indica la classe che non è stata trovata e la classe che ha il riferimento non valido. La posizione è identificata in base alle istruzioni specifiche di Dalvik. Il trucco è guardare nei log sopra l'eccezione.


6
Anche guardare sopra l'eccezione mi ha aiutato a identificare il metodo che causava l'errore. Per me, era l'espressione Build.VERSION.SDK_INT> = Build.VERSION_CODES.ECLAIR che è abbastanza ovvio, alla fine, se lo provi su Cupcake ...
Manuel

2
Grazie! Questo era il problema che stavo ottenendo ... i log utili erano appena sopra l'eccezione: WARN/dalvikvm(1052): VFY: unable to resolve static method 475: Ljavax/xml/datatype/DatatypeFactory;.newInstance ()Ljavax/xml/datatype/DatatypeFactory;(ora per capire come fare a meno di DatatypeFactory)
pyko

Guardare sopra l'errore mi ha aiutato anche. Cerca un messaggio che inizi con "VFY:" Nel mio caso, dice "Rifiuto arbitrariamente metodo di grandi dimensioni". Probabilmente perché crea un numero enorme di array :) comunque, grazie per il suggerimento!
Amplify91

Grazie! Ho scoperto che il mio problema riguardava il gestore delle eccezioni: NetworkOnMainThreadException non è implementato in Android 2.3. Guarda in basso per la mia risposta. Grazie ancora! :)
Seraphim's

Grazie! Nel mio caso, stavo prendendo di mira Android2.3 e stavo usando android-support-v4.jar, e non trovavo le classi in questo jar. Ho dovuto fare clic sulla scheda "esporta" per questa classe nelle proprietà e portarla sopra la libreria android2.3.3. Bene, questa esportazione è davvero qualcosa che non capisco chiaramente ...
xtof54

14

Per farlo funzionare è necessario aggiungere il jar della libreria a una delle cartelle di origine (anche se l'hai già aggiunto come libreria di eclipse, devi comunque aggiungerlo come sorgente).

  1. Crea una directory nel tuo progetto (ex "libs") e mettici il jar della libreria.
  2. Aggiungi la directory al percorso della classe di compilazione tramite (fai clic con il pulsante destro del mouse sulla cartella e seleziona "Percorso di creazione" -> "Usa come cartella di origine").
  3. Ricostruisci il tuo progetto.

Possiamo aggiungere una "Libreria del progetto" invece di un JAR alla cartella "libs"?
Ahmed

Strano ... ho dovuto aggiungerlo come una normale libreria Java - non come una libreria nel menu "Android" in Eclipse.
Phil

Grazie Maksim, bella soluzione.
Arun Badole

8

Mi è successo proprio adesso. L'errore è stato causato perché stavo usando i metodi di un SDK più recente del mio dispositivo.

Il dispositivo Android 1.5 ha installato un apk utilizzando questo:

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

8

Ho trovato un caso interessante. Io uso:

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

Quindi alcune delle nuove funzionalità di Android 4 non sono implementate in Android 2.3 come ImageView.setLayerType. Per evitare errori di runtime semplicemente:

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

Questo approccio dovrebbe essere utilizzato anche con la gestione delle eccezioni:

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

NetworkOnMainThreadExceptionnon è implementato in Android 2.3 quindi quando la classe viene caricata (e non prima!) si java.lang.VerifyErrorverifica l'eccezione .


1
Lo stesso è accaduto con me. Ho usato java.lang.ReflectiveOperationExceptionche non è incluso nelle versioni precedenti di Android (ad esempio 4.2), ma Lint non mi ha avvertito di questo ...
WonderCsabo

Per me il problema è il mio codice dichiara a CameraAccessException, che è stato introdotto in Android 5.0, ma quando corro su un dispositivo Android 4.3, viene lanciato il VerifyError.
Piasy

7

Se stai usando Retrolambda potresti aver aggiunto un metodo statico a un'interfaccia (che è consentito solo in Java 8).


7

Ciò può verificarsi anche a causa dell'errore del limite di riferimento su Lollypop sotto le versioni, dove è limitato fino a una dimensione massima di 65K

Possibile soluzione per il problema di cui sopra

Passo 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

Passaggio 2: estendi la tua applicazione con MultiDexApplication, ad es

public class MyApplication extends MultiDexApplication

Passaggio 3: eseguire l'override di attachBaseContext

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

Passaggio 4: il passaggio successivo è aggiungere quanto segue alla parte Android delle tue app build.gradle

 dexOptions {
      preDexLibraries = false
   }

Passaggio 5: infine, seguendo la parte generale delle tue app build.gradle

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

Per i dettagli, controlla

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


Ha funzionato per me !! non dimenticare di cambiare la classe dell'applicazione in "MultiDexApplication".
Ganesh

Mi hai salvato molto tempo amico. Questa dovrebbe essere la risposta accettata.
Rohit Rokde

3

Nel mio caso, è successo quando ho aggiornato da Eclipse Indigo a Eclipse Juno: non sono sicuro di quale sia il vero motivo, ma il mio progetto Android su cui sto lavorando da molto tempo ha smesso di funzionare a causa di quell'eccezione.

Dopo molti ore di tentativi di risolverlo, ho trovato la soluzione per me.

Nel mio progetto Android, utilizzo un altro progetto (ad esempio "MyUtils") che si trova nella stessa area di lavoro. Quindi, dovevo fare quanto segue:

Fare clic con il pulsante destro del mouse su Progetto Android -> Percorso build -> Configura percorso build

Ora vai alla scheda "Ordina ed esporta" e seleziona "MyUtils". Ecco fatto: mi sono sbarazzato di questa fastidiosa eccezione.


Questo è ciò che ha risolto il problema per me ... abbiamo un grande progetto quindi sono andato in giro e ho controllato il flag "export" su tutto. Problema PITA.
Someone Somewhere

3

Ho eseguito il downgrade della versione gradle da 2.0.0-alpha2 a 1.5.0 che ha risolto questo problema.


2

Il problema potrebbe anche essere causato da una mancata corrispondenza tra due progetti androidi. Ad esempio, se hai sviluppato una libreria Android utilizzando il pacchetto "com.yourcompany", allora il progetto dell'applicazione principale utilizza lo stesso pacchetto del pacchetto base. Quindi supponiamo che tu voglia modificare la versione della tua app principale, quindi modifichi i valori del file manifest: Codice versione e Nome versione. Se esegui la tua app senza modificare quei valori per la libreria, riceverai un errore di verifica su qualsiasi chiamata di un metodo su un oggetto dalla libreria.


2

Ho avuto lo stesso problema. Stavo costruendo con 2.1 r1 e aggiornato a 2.1 r3 con il nuovo adt 17. Ho avuto errori di verifica su mail.jar di javamail e mi stava facendo impazzire. Ecco come ho risolto il problema:

  1. ha creato una cartella libs / e aggiunto i jars.
  2. fare clic con il tasto destro> aggiungi come cartella di origine

ho provato una ricostruzione e non è riuscita. Ho rimosso la directory libs / come cartella di origine e ho rimosso i riferimenti ai 3 file jar nel percorso di build. Quindi ho aggiunto di nuovo la cartella libs / e ho aggiunto ogni jar nella cartella libs / al percorso di compilazione. Ora funziona come previsto. Questa è una strana soluzione alternativa ma ha funzionato per me.


2

In Eclipse 4.x, se si verifica questo problema, provare qui di seguito:

  1. migrare tutti i barattoli di terze parti inclusi in User-Libaray
  2. sposta in alto la libreria utente prima della libreria Android e selezionala nella scheda Ordine ed esportazione
  3. pulire e ricostruire per funzionare

2

Ho questo problema dopo un aggiornamento dell'SDK. Il compilatore ha avuto problemi con le mie librerie esterne. Ho fatto questo: fai clic con il pulsante destro del mouse sul progetto, quindi "Strumenti Android> aggiungi libreria di supporto ..." questa installazione sulla libreria del mio progetto "android-support-v4.jar".


2

java.lang.VerifyErrorsignifica che il tuo bytecode compilato si riferisce a qualcosa che Android non riesce a trovare in fase di runtime. Questa verificaErrore mi dà problemi solo con kitkat4.4 e una versione inferiore non nella versione precedente di quella anche se ho eseguito la stessa build in entrambi i dispositivi. quando ho usato il parser jackson json della versione precedente si vedejava.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.+'

Quindi ho cambiato la dipendenza all'ultima versione da 2.2 a 2.7 senza la libreria principale (quando includo core2.7 dà il verifyError), quindi funziona. il che significa che i metodi e gli altri contenuti del core vengono migrati all'ultima versione di Databind2.7 . Questo risolve i miei problemi.

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

1

Ricevo anche VerfiyError ... non riesco a trovare una vera ragione. Aiuta a racchiudere le nuove righe di codice in un metodo (Eclipse, "Extract Method ..."). Quindi nel mio caso il motivo non è un metodo non supportato.


1

Ho avuto un problema molto simile. Avevo aggiunto Apache POI barattoli e il problema è apparso quando ho aggiornato ad Android SDK 22.3.

Ho controllato le librerie private Android, quindi questo non era il problema comune con Android SDK. Ho deselezionato tutti i jar POI di Apache e li ho aggiunti uno per uno. Ho scoperto che poi-3.9-20121203.jar dovrebbe essere prima di poi-ooxml-3.9-20121203.jar . Altrimenti non funzionerà.


1

Se hai dei test, prova a commentare questa riga dal tuo build.gradefile:

testCoverageEnabled = true

Per me questo ha causato eccezioni VerifyError sulle classi che utilizzano le funzionalità Java 1.7, in particolare le istruzioni di commutazione di stringa.


1

Ho avuto lo stesso problema dopo aver fatto un git pull.

Soluzione: Build -> Clean Project.

Spero che questo ti aiuti.


1
Non ho tirato o fatto nulla, ma è stato pulito, grazie!
Alexandre G

1

Ho trovato un altro caso.

condizioni:

  • Usa Retrolambda (non so se è necessario);
  • Crea un metodo statico in un'interfaccia.

E il risultato è boom! java.lang.VerifyError quando si tenta di accedere alla classe che utilizza quell'interfaccia. Sembra che ad Android (4.4. * Nel mio caso) non piacciano i metodi statici nelle interfacce. La rimozione del metodo statico dall'interfaccia fa scomparire VerifyError.


0

Ho anche avuto questo problema, così come i miei vasi in una libreria utente ...

Il modo in cui ho risolto questo problema è stato aggiungerli alla cartella lib e quindi aggiungerli nelle proprietà di build in eclipse ...

La prima volta che l'ho fatto non ha funzionato, ma poi li ho rimossi e li ho riletti di nuovo e ha iniziato a funzionare ...

un po 'strano! ma ora lavora tutto il tempo.

In bocca al lupo


0

Ho codificato metodi / classi API Android che si trovano in SDK 2.1 e stavo cercando di eseguirlo sull'emulatore Android 1.6. Quindi ho ricevuto quell'errore.

SOLUZIONE: modificato per correggere la versione dell'emulatore.

QUESTO HA FUNZIONATO PER ME .. Grazie.


0

Per i posteri, ho appena ricevuto questo errore perché stavo usando Arrays.copyOf()che non è un metodo supportato da Java 1.5 che corrisponde ad Android Livello 4. Poiché stavo utilizzando le librerie sviluppate con la versione 1.6, si compilavano bene. Ho visto i problemi solo quando ho spostato la classe in questione nel mio progetto Android, quindi l'errore è stato evidenziato.

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)

Su quella riga stavo cercando di fare un new DaoConfigArraye quella classe aveva la seguente riga:

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

Ciò che lo ha reso ancora più complicato è che la riga 71 puntava a ThreadLocalun'inizializzazione che inizialmente pensavo fosse la ragione del problema.

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

0

Ho dovuto rimuovere i progetti dipendenti e invece compilare i progetti dipendenti sono jar e includerli nella cartella libs.


0

Sono sicuro che la mia causa fosse diversa dalla tua, ma poiché questo è uno dei risultati migliori durante la ricerca di "Android java.lang.VerifyError", ho pensato di registrarlo qui per i posteri.

Ho tenuto alcune lezioni sulla falsariga di:

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

E un metodo che ha fatto:

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

// Fill result
...

Finché questo codice era presente nel file, avrei ricevuto un VerifyError la prima volta che veniva caricata la classe contenente questo metodo. Dividendolo in due metodi separati (uno che si occupava solo di B e uno che trattava solo di C) ha risolto il problema.


1
E, a proposito, il modo in cui l'ho causato come root era commentando i corpi del metodo (sostituendo con return null / 0 / false) fino a quando VerifyError non è andato via, quindi ripristinando le cose finché non è tornato di nuovo; quindi fare lo stesso all'interno del metodo del problema. Non è un modo divertente per eseguire il debug, certo, ma ha funzionato.
benkc

0

Nel mio caso, questo errore si verifica perché il mio servizio Google Play non è il più recente .

Se il tuo progetto non supporta alcune classi nel .jar, si verifica questo errore (es. ImageView.setLayerType, AdvertisingIdClient, ecc.).


0

Ho appena identificato un'altra situazione che si verifica, non solo a causa di libs non dx 'ed. Ho un AsyncTask con un mehtod doInBackground molto lungo. Per qualche motivo questo metodo con più di 145 righe ha iniziato a interrompersi. È successo su un'app 2.3. Quando ho appena incapsulato alcune parti in metodi, ha funzionato bene.

Quindi, per coloro che non riusciva a trovare la classe che non è stato correttamente dx 'ed, provare a ridurre la lunghezza del vostro metodo.


0

Per me, il problema è finito per essere effettivamente che stavo usando la clausola multi-catch da qualche parte nella classe che è una funzionalità di Java 7 (e API 19+). Quindi andrebbe in crash con VerifyErrorsu tutti i dispositivi precedenti alla 19.


0

Per me era in correlazione tra compileSdkVersion e buildToolsVersion. Avevo:

compileSdkVersion 21
buildToolsVersion '19.1.0'

L'ho cambiato in:

compileSdkVersion 21
buildToolsVersion '21.1.2'

0

Per me, è il problema di compileSdkVersion. Quando ho utilizzato il livello API 21 in una specifica applicazione Android ( https://github.com/android10/Android-AOPExample ):

compileSdkVersion 21

si è verificato l'errore java.lang.verify. Quindi ho cambiato compileSdkVersion a 19

compileSdkVersion 19

Ha funzionato bene. Penso che potrebbe essere il problema di SDK buildTools e sembra OK quando il livello API <21.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.