Android java.lang.Excepción verifyerror?

https://stackoverflow.com/questions/668788

21-08-2019
|

Pregunta

En mi app de Android, siempre me VerifyErrors!Y no puedo entender por qué.Siempre que puedo incluir un JAR externo, siempre me VerifyErrors cuando intento iniciar mi aplicación (excepto una vez, cuando yo incluido Apache Log4j.)

Yo generalmente de conseguir alrededor de esto, tomando el origen de la biblioteca y agregarlo a mi proyecto, pero estoy tratando de poner el GData biblioteca de cliente.

Puedo conseguir esta en el origen, pero se trata de dependencias (mail.jar, activation.jar, servlet-api.jar) no puedo, así que tengo verificar errores.Me gustaría llegar a la raíz de este problema de una vez por todas.Busqué en internet, pero todos ellos parecen hablar incompleta archivos de clase?que no conozco.

Solución

Android utiliza un formato de archivo de clase diferente. ¿Está ejecutando los archivos JAR 3er partido a través de la función "dx" que se incluye con el SDK de Android?

Otros consejos

Mira LogCat y ver lo que está causando el VerifyError. Es probable que algún método en una clase java.lang que no es compatible en el nivel SDK de Android que está utilizando (por ejemplo, String.isEmpty ()).

android-developers :

La salida de "Logcat adb" indica la clase que no pudo ser encontrado, así como la clase que tiene la mala referencia. La locación se identifica a la instrucción específica Dalvik. El truco es para buscar en los registros por encima de la excepción.

Para hacer que funcione es necesario agregar frasco de la biblioteca a una de las carpetas de origen (incluso si ya lo ha añadido biblioteca como eclipse, usted todavía necesita para agregarlo como fuente).

Crear un directorio en su proyecto (E.x. "libs") y poner el tarro biblioteca ahí.
Añadir el directorio a la clase build camino por el (haga clic en el botón derecho carpeta y seleccione "Construir camino" -> "Uso como carpeta de origen ").
Reconstruir su proyecto.

Le pasó a mí en este momento. El error fue causado porque estaba usando métodos de un SDK más reciente que tenía mi dispositivo.

Android 1.5 dispositivo instalado un APK utilizando la siguiente:

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

He encontrado un caso interesante. Yo uso:

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

Así que algunos de los nuevos Android 4 capacidades no están implenented en Android 2.3 como ImageView.setLayerType. Para evitar errores de tiempo de ejecución simplemente:

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

Este enfoque debe ser utilizado también con el manejo de excepciones:

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

NetworkOnMainThreadException no se implementa en Android 2.3 por lo que cuando se carga el class (y no antes!) La excepción java.lang.VerifyError se produce.

Si está utilizando Retrolambda que podría haber añadido un método estático a una interfaz (que sólo se permite en Java 8).

Esto también puede ocurrir porque en incluir error límite en Lollypop debajo de versiones, en las que se limita hasta el tamaño máximo de 65K

Posible solución para el problema anterior

Paso 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

Paso 2:. Extender su aplicación con MultiDexApplication, para por ejemplo

public class MyApplication extends MultiDexApplication

Paso 3: Reemplazar attachBaseContext

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

Paso 4: El siguiente paso es añadir lo siguiente a la parte androide de sus aplicaciones build.gradle

 dexOptions {
      preDexLibraries = false
   }

Paso 5: Por último, siguiendo a la parte general de su aplicaciones build.gradle

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

Para más detalles, por favor, pago y envío

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

En mi caso, me ha pasado cuando he actualizado desde Eclipse Indigo para Eclipse Juno:No estoy seguro de cuál es la verdadera razón, pero, mi proyecto Android en la que estoy trabajando desde hace mucho tiempo dejó de trabajar debido a que la excepción.

Después de muchos horas tratando de arreglar eso, he encontrado la solución para mí.

En mi proyecto Android, yo uso otro proyecto (por ejemplo, "MyUtils") que está en la misma área de trabajo.Así, necesitaba hacer lo siguiente:

Haga clic derecho en Android project -> Build path -> Configure build path

Ahora, vaya a la pestaña de "Orden y a la Exportación" y hacer "MyUtils" marcada.Eso es todo:Me deshice de este molesto excepción.

Downgrade versión 2.0.0 de Gradle-alfa 2 a 1.5.0 que soluciona este problema.

El problema también puede ser causado por un desajuste entre dos proyectos androides. Por ejemplo, si ha creado una biblioteca de Android con el paquete "com.yourcompany", entonces usted tiene el proyecto de la aplicación principal usando el mismo paquete como paquete base. Entonces deja que dice que quiere cambiar la versión de su aplicación principal, por lo que se modifican los valores del archivo de manifiesto: código de la versión y el nombre de la versión. Si ejecuta su aplicación sin necesidad de cambiar los valores de la biblioteca, se llega a un proceso de verificación de error en cualquier llamada de un método en un objeto de la biblioteca.

Yo tenía el mismo problema. Yo estaba construyendo con 2,1 R1 y R3 actualizado a 2.1 con el nuevo ADT 17. Tenía verificar errores en mail.jar de Javamail y me estaba volviendo loco. Aquí es cómo resolvió el problema:

creó un libs / carpeta y añade los frascos.
clic derecho> añadir al carpeta de origen

he intentado una reconstrucción y falló. Quité el libs / directorio que una carpeta de origen y quité referencias a los archivos 3 tarro en la trayectoria de la estructura. Luego añade la libs / carpeta de nuevo, y añadí cada frasco en el libs / carpeta a la trayectoria de la estructura. Ahora funciona como se esperaba. Esta es una solución extraña pero funcionó para mí.

En Eclipse 4.x, si se encuentra con este problema, pruebe a continuación:

migrar todos los frascos 3o proveedores incluida en el User-libaray
ascender en la lib usuario antes de la lib androide y comprobarlo en la ficha Orden y exportación
limpia y reconstruir a ejecutar

Tengo este problema después de una actualización del SDK. El compilador tuvo problemas con mis librerias externas. Hice esto: haga clic derecho en el proyecto, luego "Herramientas del androide> añadir biblioteca suport ..." esta instalación en mi biblioteca de proyectos "android-support-v4.jar".

Me da la VerfiyError así ... no puede encontrar una razón real. Ayuda a envolver las nuevas líneas de código en un método (Eclipse, 'Extraer método ...'). Así que en mi caso, la razón no es un método no compatible.

Yo tenía un problema muy similar. Había añadido Apache POI jarras y el problema apareció cuando he actualizado a Android SDK 22.3.

tuve Android privadas Bibliotecas comprobado por lo que este no era el problema común con los SDK de Android. Que yo no se los Apache POI frascos y añadió uno por uno. He descubierto que poi-3.9-20121203.jar debería ser antes de poi-OOXML-3.9-20121203.jar . De lo contrario, no funcionará.

Si usted tiene pruebas, tratar comentando esta línea desde su build.grade archivo:

testCoverageEnabled = true

Para mí esto provocó excepciones VerifyError sobre las clases que utilizan Java 1.7 características, en particular las sentencias switch cadena.

Yo tenía el mismo problema después de hacer un git pull.

Solución:. Build -> Proyecto Clean

Espero que esto ayude.

He encontrado otro caso.

Condiciones:

Uso Retrolambda (no estoy seguro si es necesario);
Establecer un método estático en una interfaz.

Y el resultado es boom! java.lang.VerifyError al intentar acceder a la clase que utiliza la interfaz. Parece que Android (4.4. * En mi caso) no le gustan los métodos estáticos en las interfaces. Extracción del método estático de la interfaz hace VerifyError desaparecerá.

java.lang.VerifyError significa que su código de bytes compilado se refiere a algo que Android no puede encontrar en tiempo de ejecución. Esta Problemas VerifyError mí sólo con kitkat4.4 y menor versión no en la versión anterior de que incluso corrió la misma estructura en ambos dispositivos. cuando solía Jackson analizador JSON de versión anterior que muestra <=>

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.+'

Entonces me han cambiado la dependencia a la última versión 2.2 a 2.7 sin la biblioteca núcleo (cuando incluyo core2.7 da la VerifyError), entonces funciona . lo que significa que los métodos y otros contenidos de core se migra a la versión más reciente de Databind2.7 . Esto ha solucionado mis problemas.

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

también tuve este problema, al igual que mis frascos en una librería de usuario ...

La forma en que esto fue resuelto para añadirlos a la carpeta lib y luego añadirlos en las propiedades de construcción en Eclipse ...

La primera vez que hice esto no funcionó, pero luego me los quitó y los readded de nuevo y comenzó a trabajar ...

poco de un extraño! pero ahora trabajando todo el tiempo.

Buena suerte

He codificado métodos de la API de Android / clase que se encuentran en SDK 2.1, y estaba tratando de ejecutarlo en Android 1.6 emulador. Así que me dio ese error.

SOLUCIÓN: Lo cambió a corregir la versión del emulador.

ESTA TRABAJADO para mí .. Gracias.

Para la posteridad, acabo de recibir este error debido a que estaba usando Arrays.copyOf() que no es un método compatible con Java 1.5, que corresponde a Android en el Nivel 4.Porque me estaba quedando incluidas las bibliotecas, desarrollado bajo la 1.6 se compila bien.Yo sólo vi los problemas cuando me mudé a la clase en cuestión a mi proyecto Android, entonces el error fue resaltada.

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)

En esa línea, yo estaba tratando de hacer un new DaoConfigArray y que clase tiene la siguiente línea:

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

Lo que hizo aún más complicado es que la línea 71 se apunta a un ThreadLocal la inicialización, que yo pensaba que era la razón para el problema inicialmente.

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

tuve que quitar los proyectos dependientes y en lugar de compilar proyectos son dependientes del frasco e incluirlos en la carpeta libs.

Estoy seguro de que mi causa era diferente a la suya, pero ya que este es uno de los principales éxitos en la búsqueda de "Android java.lang.VerifyError", pensé que grabo aquí para la posteridad.

Yo tenía algunas clases a lo largo de las líneas de:

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

Y un método que hizo:

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

// Fill result
...

Mientras este código estaba presente en el archivo, me gustaría tener un VerifyError la primera vez que se ha cargado la clase que contiene este método. Dividiendo hacia fuera en dos métodos separados (uno que se refería únicamente a B, y uno que se ocupan únicamente con C de) fijado el problema.

En mi caso, se produce este error porque mi Google play-servicio no es el más nuevo .

Si su proyecto no es compatible con alguna clase en el .jar, se produce este error (ej. ImageView.setLayerType, AdvertisingIdClient, etc.).

Me acaban de identificar otra situación que se produce, no sólo debido a las librerías no dx 'ed. Tengo un AsyncTask con una muy larga mehtod doInBackground. Por alguna razón este método con más de 145 líneas comenzó a romper. Sucedió en una aplicación 2.3. Cuando acabo de encapsulado algunas partes en métodos, que funcionaba bien.

Así que para aquellos que no pudieron encontrar la clase que no estaba correctamente dx 'ed, intente reducir la duración de su método.

Para mí, el asunto terminó en realidad es que yo estaba usando la cláusula multi-trampa en alguna parte en la clase, que es una característica de 7 de Java (API y 19+). Por lo tanto, se estrellaría con VerifyError en todos los dispositivos pre-19.

Para mí fue en correlación entre compileSdkVersion y buildToolsVersion. Tenía:

compileSdkVersion 21
buildToolsVersion '19.1.0'

He cambiado a:

compileSdkVersion 21
buildToolsVersion '21.1.2'

Para mí, es el problema de compileSdkVersion. Cuando solía el nivel API 21 en una aplicación de androide específico ( https://github.com/android10 / Android -AOPExample):

compileSdkVersion 21

ocurrió el java.lang.verifyerror. Así que cambié el compileSdkVersion a 19

compileSdkVersion 19

Aunque funcionaba bien. Creo que podría ser el problema de buildTools SDK, y parece bien cuando el nivel de API <21

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow