Android java.lang.VerifyError?

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.

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?

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

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.

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.

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

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 .

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

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

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.

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

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.

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.

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

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

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'

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.

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

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.

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

Soluzione: Build -> Clean Project.

Spero che questo ti aiuti.

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.

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

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.

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

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

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.

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

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.

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.

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'

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.