Android java.lang.VerifyError?

En mi aplicación de Android, siempre obtengo VerifyErrors. Y no puedo entender por qué. Siempre que incluyo un JAR externo, siempre obtengo VerifyErrors cuando intento iniciar mi aplicación (excepto una vez, cuando incluí Apache Log4j).

Por lo general, soluciono esto tomando la fuente de la biblioteca y agregándola a mi proyecto, pero estoy tratando de poner la biblioteca cliente de GData .

Puedo obtener esto en la fuente, pero sus dependencias (mail.jar, activación.jar, servlet-api.jar) no puedo, así que obtengo errores de verificación. Me gustaría llegar a la raíz de este problema de una vez por todas. Busqué en Internet, pero todos parecen hablar de archivos de clase incompletos. que no conozco.

Android usa un formato de archivo de clase diferente. ¿Está ejecutando archivos JAR de terceros a través de la herramienta "dx" que se incluye con el SDK de Android?

Mire LogCat y vea qué está causando el error de verificación. Probablemente sea algún método en una clase java.lang que no es compatible con el nivel de SDK de Android que está utilizando (por ejemplo, String.isEmpty ()).

De los desarrolladores de Android :

El resultado de "adb logcat" indica la clase que no se pudo encontrar, así como la clase que tiene la referencia incorrecta. La ubicación se identifica hasta la instrucción específica de Dalvik. El truco consiste en buscar en los registros sobre la excepción.

Para que funcione, debe agregar el jar de la biblioteca a una de las carpetas de origen (incluso si ya lo ha agregado como biblioteca de eclipse, aún debe agregarlo como fuente).

1. Cree un directorio en su proyecto (ex "libs") y coloque el jar de la biblioteca allí.
2. Agregue el directorio a la ruta de la clase de compilación (haga clic en el botón derecho de la carpeta y seleccione "Ruta de compilación" -> "Usar como carpeta de origen").
3. Reconstruye tu proyecto.

Me pasó a mí ahora mismo. El error se debió a que estaba usando métodos de un SDK más nuevo que tenía mi dispositivo.

El dispositivo Android 1.5 instaló un apk usando esto:

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

Encontré un caso interesante. Yo suelo:

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

Así que algunas de las nuevas capacidades de Android 4 no están implementadas 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 usarse también con el manejo de excepciones:

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

NetworkOnMainThreadExceptionno está implementado en Android 2.3, por lo que cuando se carga la clase (¡y no antes!) se java.lang.VerifyErrorproduce la excepción .

Si está utilizando Retrolambda, es posible que haya agregado un método estático a una interfaz (que solo está permitido en Java 8).

Esto también puede ocurrir debido al error de límite de referencia en las versiones inferiores de Lollypop, donde está limitado hasta un 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: amplíe su aplicación con MultiDexApplication, por ejemplo

public class MyApplication extends MultiDexApplication

Paso 3: anular attachBaseContext

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

Paso 4: El siguiente paso es agregar lo siguiente a la parte de Android de la compilación de aplicaciones.

 dexOptions {
      preDexLibraries = false
   }

Paso 5: Por último, siguiendo la parte general de la compilación de aplicaciones.

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

Para obtener más información, consulte

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

En mi caso, sucedió cuando actualicé de Eclipse Indigo a Eclipse Juno: no estoy seguro de cuál es la verdadera razón, pero mi proyecto de Android en el que estoy trabajando durante mucho tiempo dejó de funcionar debido a esa excepción.

Después de muchas horas de intentar arreglar eso, encontré la solución para mí.

En mi proyecto de Android, uso otro proyecto (por ejemplo, "MyUtils") que está en el mismo espacio de trabajo. Entonces, necesitaba hacer lo siguiente:

Haga clic derecho en el proyecto de Android -> Ruta de compilación -> Configurar ruta de compilación

Ahora, vaya a la pestaña "Ordenar y exportar" y marque "MyUtils". Eso es todo: me deshice de esta molesta excepción.

Bajé la versión de gradle de 2.0.0-alpha2 a 1.5.0 que resolvió este problema.

El problema también podría deberse a un desajuste entre dos proyectos de androides. Por ejemplo, si ha desarrollado una biblioteca de Android usando el paquete "com.yourcompany", entonces tiene el proyecto de la aplicación principal usando el mismo paquete que el paquete base. Luego, digamos que desea cambiar la versión de su aplicación principal, por lo que cambia los valores del archivo de manifiesto: Código de versión y Nombre de versión. Si ejecuta su aplicación sin cambiar esos valores para la biblioteca, obtendrá un error de verificación en cualquier llamada de un método en un objeto de la biblioteca.

Tuve el mismo problema. Estaba construyendo con 2.1 r1 y actualizado a 2.1 r3 con el nuevo adt 17. Tenía errores de verificación en el mail.jar de javamail y me estaba volviendo loco. Así es como resolví el problema:

1. creó una carpeta libs / y agregó los frascos.
2. clic derecho> agregar como carpeta de origen

Intenté una reconstrucción y falló. Eliminé el directorio libs / como carpeta de origen y eliminé las referencias a los 3 archivos jar en la ruta de compilación. Luego agregué la carpeta libs / nuevamente y agregué cada jar en la carpeta libs / a la ruta de compilación. Ahora funciona como se esperaba. Esta es una solución extraña, pero funcionó para mí.

En Eclipse 4.x, si encuentra este problema, intente a continuación:

1. migrar todos los frascos de terceros incluidos a User-Libaray
2. mueva la biblioteca de usuario antes de la biblioteca de Android y verifíquela en la pestaña Orden y exportación
3. limpiar y reconstruir para funcionar

Tengo este problema después de una actualización del SDK. El compilador tuvo problemas con mis bibliotecas externas. Hice esto: haga clic derecho en el proyecto, luego "Herramientas de Android> agregar biblioteca de soporte ..." esta instalación en la biblioteca de mi proyecto "android-support-v4.jar".

java.lang.VerifyErrorsignifica que su código de bytes compilado se refiere a algo que Android no puede encontrar en tiempo de ejecución. Este verifyError me emite solo con kitkat4.4 y una versión menor, no en la versión anterior, incluso yo ejecuté la misma compilación en ambos dispositivos. cuando utilicé el analizador jackson json de la versión anterior, se muestrajava.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.+'

Luego cambié Dependancy a la última versión 2.2 a 2.7 sin la biblioteca central (cuando incluyo core2.7 da el verifyError), entonces funciona. lo que significa que los métodos y otros contenidos del núcleo se migran a la última versión de Databind2.7 . Esto soluciona 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 recibo VerfiyError ... no puedo encontrar una razón real. Ayuda a envolver las nuevas líneas de código en un método (Eclipse, 'Extraer método ...'). Entonces, en mi caso, la razón no es un método no admitido.

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

Hice comprobar las bibliotecas privadas de Android, por lo que este no era el problema común con el SDK de Android. Desmarqué todos los frascos de Apache POI y agregué uno por uno. Encontré que poi-3.9-20121203.jar debería estar antes de poi-ooxml-3.9-20121203.jar . De lo contrario, no funcionará.

Si tiene pruebas, intente comentar esta línea de su build.gradearchivo:

testCoverageEnabled = true

Para mí, esto causó excepciones VerifyError en clases que usan características de Java 1.7, particularmente declaraciones de cambio de cadena.

Tuve el mismo problema después de hacer un git pull.

Solución: Construir -> Proyecto Limpio.

Espero que esto ayude.

Encontré otro caso.

Condiciones:

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

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

También tuve este problema, al igual que mis jarras en una biblioteca de usuario ...

La forma en que resolví esto fue agregarlos a la carpeta lib y luego agregarlos en las propiedades de compilación en eclipse ...

La primera vez que hice esto no funcionó, pero luego los quité y los volví a leer y comenzó a funcionar ...

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

Buena suerte

He codificado métodos / clases de API de Android que están en SDK 2.1 y estaba tratando de ejecutarlo en el emulador de Android 1.6. Entonces obtuve ese error.

SOLUCIÓN: Se cambió a la versión correcta del emulador.

ESTO FUNCIONÓ PARA MÍ .. Gracias.

Para la posteridad, acabo de recibir este error porque estaba usando Arrays.copyOf()un método que no es compatible con Java 1.5 y que corresponde al nivel 4 de Android. Debido a que estaba ejecutando, incluidas las bibliotecas desarrolladas en 1.6, se compilaron bien. Solo vi los problemas cuando moví la clase en cuestión a mi proyecto de Android, luego se resaltó el error.

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 estaba tratando de hacer una new DaoConfigArrayy esa clase tenía la siguiente línea:

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

Lo que lo hizo aún más complicado es que la línea 71 apuntaba a una ThreadLocalinicialización que pensé que era la razón del problema inicialmente.

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

Tuve que eliminar proyectos dependientes y, en su lugar, compilar proyectos dependientes que son jar e incluirlos en la carpeta libs.

Estoy seguro de que mi causa era diferente a la tuya, pero dado que este es uno de los principales éxitos al buscar "Android java.lang.VerifyError", pensé en grabarlo aquí para la posteridad.

Tuve algunas clases en la línea 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
...

Siempre que este código estuviera presente en el archivo, obtendría un VerifyError la primera vez que se cargara la clase que contiene este método. Dividirlo en dos métodos separados (uno que trataba solo con B y otro que solo trataba con C) solucionó el problema.

En mi caso, este error ocurre porque mi servicio google-play no es el más nuevo .

Si su proyecto no admite alguna clase en el .jar, se produce este error (por ejemplo, ImageView.setLayerType, AdvertisingIdClient, etc.).

Acabo de identificar otra situación en la que ocurre, no solo debido a libs no dx 'ed. Tengo una AsyncTask con un método doInBackground muy largo. Por alguna razón, este método con más de 145 líneas comenzó a romperse. Ocurrió en una aplicación 2.3. Cuando encapsulé algunas partes en métodos, funcionó bien.

Entonces, para aquellos que no pudieron encontrar la clase que no fue correctamente editada , intente reducir la longitud de su método.

Para mí, el problema terminó siendo en realidad que estaba usando una cláusula de captura múltiple en algún lugar de la clase, que es una característica de Java 7 (y API 19+). Por lo tanto, fallaría VerifyErroren todos los dispositivos anteriores a 19.

Para mí, estaba en correlación entre compileSdkVersion y buildToolsVersion. Yo tenía:

compileSdkVersion 21
buildToolsVersion '19.1.0'

Lo cambié a:

compileSdkVersion 21
buildToolsVersion '21.1.2'

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

compileSdkVersion 21

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

compileSdkVersion 19

Funcionó bien. Creo que podría ser el problema de SDK buildTools, y parece estar bien cuando el nivel de API es <21.