Android java.lang.VerifyError?
gdata (30)
En mi aplicación para Android, ¡siempre obtengo VerifyErrors! Y no puedo entender por qué. Cada vez que incluyo un JAR externo, siempre obtengo VerifyErrors cuando intento iniciar mi aplicación (excepto por una vez, cuando incluí Apache Log4j).
Por lo general, soluciono esto tomando el origen de la biblioteca y agregándola a mi proyecto, pero estoy tratando de poner la biblioteca del cliente GData .
Puedo obtener esto en fuente, pero son dependencias (mail.jar, activation.jar, servlet-api.jar) No puedo, entonces 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 parece que todos hablan de archivos de clase incompletos. de lo que no sé.
Acabo de identificar otra situación que ocurre, no solo debido a las bibliotecas no dx ''ed. Tengo un AsyncTask con un muy largo doInBackground mehtod. Por alguna razón, este método con más de 145 líneas comenzó a romperse. Sucedió en una aplicación de 2.3. Cuando acabo de encapsular algunas partes en métodos, funcionó bien.
Entonces, para aquellos que no pudieron encontrar la clase que no se ajustó correctamente, intente reducir la duración de su método.
Android usa un formato de archivo de clase diferente. ¿Está ejecutando los archivos JAR de terceros a través de la herramienta "dx" que se envía con el SDK de Android?
De android-developers :
La salida de "adb logcat" indica la clase que no se pudo encontrar, así como la clase que tiene la mala referencia. La ubicación se identifica según la instrucción Dalvik específica. El truco es buscar en los registros por encima de la excepción.
Degradé la versión de gradle de 2.0.0-alpha2 a 1.5.0 que resolvió este problema.
El problema también podría ser causado por una falta de coincidencia entre dos proyectos de androides. Por ejemplo, si ha desarrollado una biblioteca de Android utilizando el paquete "com.yourcompany", entonces tiene el proyecto de la aplicación principal usando el mismo paquete que el paquete base. Luego, supongamos que quieres cambiar la versión de tu aplicación principal, para que puedas cambiar 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.
En Eclipse 4.x , si encuentra este problema, intente a continuación:
- migrar todos los frascos de terceros incluidos al User-Libaray
- suba la lib de usuario antes de la lib android y compruébela en la pestaña Orden y exportación
- limpiar y reconstruir para ejecutar
En mi caso, este error ocurre porque mi google-play-service no es el más nuevo .
Si su proyecto no es compatible con alguna clase en .jar, se produce este error (por ejemplo, ImageView.setLayerType, AdvertisingIdClient, etc.).
En mi caso, sucedió cuando actualicé desde 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 tratar de arreglar eso, encontré la solución para mí.
En mi proyecto de Android, utilizo 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 haga que se marque "MyUtils". Eso es: me deshice de esta molesta excepción.
Encontré un caso interesante. Yo suelo:
<uses-sdk
android:minSdkVersion="9"
android:targetSdkVersion="18" />
Por lo tanto, algunas de las nuevas capacidades de Android 4 no se implementan en Android 2.3, como ImageView.setLayerType . Para evitar el error de tiempo de ejecución simplemente:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
setLayerType(View.LAYER_TYPE_SOFTWARE, null);
}
Este enfoque se debe usar también con manejo de excepciones:
} catch (NetworkOnMainThreadException nomte) {
// log this exception
} catch (SocketTimeoutException socketTimeoutException) {
// log this exception
}
NetworkOnMainThreadException no está implementado en Android 2.3 por lo que cuando se carga la clase (¡y no antes!) Se produce la excepción java.lang.VerifyError .
Esto también puede ocurrir debido a que se hace referencia al error límite en las versiones inferiores de Lollypop, donde está limitado hasta un tamaño máximo de 65 K.
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 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: anula 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 tus aplicaciones build.gradle
dexOptions {
preDexLibraries = false
}
Paso 5: Por último, siguiendo a la parte general de tus 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 detalles, por favor pago
Estoy seguro de que mi causa fue diferente a la tuya, pero dado que este es uno de los principales éxitos cuando busco "Android java.lang.VerifyError", pensé que lo grabaría 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 esté presente en el archivo, obtendría un VerifyError la primera vez que se cargue la clase que contiene este método. Dividirlo en dos métodos separados (uno que trata solo con B y otro que trata solo con C) resolvió el problema.
He codificado los métodos / clases de Android API que están en SDK 2.1 y estaba intentando ejecutarlo en el emulador de Android 1.6. Entonces obtuve ese error.
SOLUCIÓN: Se modificó para corregir la versión del emulador.
ESTABA FUNCIONANDO PARA MÍ. Gracias.
He encontrado otro caso.
Condiciones:
- Use Retrolambda (no estoy seguro de si es necesario);
- Haz un método estático en una interfaz.
¡Y el resultado es boom! java.lang.VerifyError cuando intenta acceder a la clase que usa esa interfaz. Parece que Android (4.4. * En mi caso) no le gusta los métodos estáticos en las interfaces. Al eliminar el método estático de la interfaz, VerifyError desaparece.
Me sucedió en este momento. El error fue causado porque estaba usando métodos de un SDK más nuevo que tenía mi dispositivo.
El dispositivo Android 1.5 instaló una aplicación usando esto:
<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/>
Mire LogCat y vea qué está causando el verifyerror. Probablemente sea algún método en una clase java.lang que no sea compatible con el nivel SDK de Android que está utilizando (por ejemplo, String.isEmpty ()).
Obtengo el VerfiyError también ... no puedo encontrar una razón real. Ayuda a envolver las nuevas líneas de código en un método (Eclipse, ''Método de extracción ...''). Entonces, en mi caso, la razón no es un método no compatible.
Para la posteridad, acabo de recibir este error porque estaba usando Arrays.copyOf() que no es un método compatible con Java 1.5 que corresponde al nivel 4 de Android. Debido a que me estaba ejecutando incluidas las bibliotecas desarrolladas en 1.6 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 DaoConfigArray y 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 inicialización de ThreadLocal que inicialmente pensé que era la razón del problema.
private static final ThreadLocal<DaoConfigArray> daoConfigLevelLocal
= new ThreadLocal<DaoConfigArray>() {
@Override
protected DaoConfigArray initialValue() {
return new DaoConfigArray();
}
};
Para mí, el problema terminó siendo 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, se bloquearía con VerifyError en todos los dispositivos anteriores a 19.
Para mí, es el problema de compileSdkVersion. Cuando utilicé el nivel de API 21 en una aplicación específica de Android ( https://github.com/android10/Android-AOPExample ):
compileSdkVersion 21
el java.lang.verifyerror sucedió. Así que cambié compileSdkVersion a 19
compileSdkVersion 19
Funcionó bien Creo que podría ser el problema de SDK buildTools, y parece correcto cuando el nivel API es <21.
Para mí, estaba en correlación entre compileSdkVersion y buildToolsVersion. Tuve:
compileSdkVersion 21
buildToolsVersion ''19.1.0''
Lo cambié a:
compileSdkVersion 21
buildToolsVersion ''21.1.2''
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).
- Cree un directorio en su proyecto (por ejemplo, "libs") y coloque el archivo jar de la biblioteca allí.
- Agregue el directorio a la ruta de la clase de compilación al (haga clic en el botón derecho de la carpeta y seleccione "Ruta de compilación" -> "Usar como carpeta de origen").
- Reconstruye tu proyecto.
Si está utilizando Retrolambda, es posible que haya agregado un método estático a una interfaz (que solo está permitido en Java 8).
Si tiene pruebas, intente comentar esta línea desde su archivo build.grade :
testCoverageEnabled = true
Para mí, esto causó excepciones VerifyError en las clases que usan las características de Java 1.7, particularmente las declaraciones de cambio de cadena.
También tuve este problema, al igual que mis jarros 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 listar y comenzó a funcionar ...
un poco extraño! pero ahora trabajando todo el tiempo.
Buena suerte
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> agregue la biblioteca de soporte ..." esta instalación en la biblioteca de mi proyecto "android-support-v4.jar".
Tuve el mismo problema después de hacer un git pull.
Solución: Build -> Clean Project.
Espero que esto ayude.
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 mail.jar de javamail y me estaba volviendo loco. Así es como resolví el problema:
- creó una carpeta libs / y agregó los frascos.
- clic derecho> agregar como carpeta fuente
intenté una reconstrucción y falló. Eliminé el directorio libs / como una carpeta de origen y eliminé 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í.
Tuve que eliminar proyectos dependientes y, en su lugar, compilar proyectos dependientes son jar e incluirlos en la carpeta libs.
Tuve un problema muy similar. Agregué los archivos de PDI de Apache y apareció el problema cuando actualicé a Android SDK 22.3.
Tenía bibliotecas privadas de Android marcadas, por lo que este no era el problema común con el SDK de Android. Desmarqué todas las jarras de POI de Apache y agregué una por una. Descubrí que poi-3.9-20121203.jar debería estar antes de poi-ooxml-3.9-20121203.jar . De lo contrario, no funcionará.
java.lang.VerifyError significa que su bytecode 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 cuando ejecuté la misma compilación en ambos dispositivos. cuando utilicé el analizador jackson json de una versión anterior, muestra 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.+''
Luego cambié la Dependencia a la última versión 2.2 a 2.7 sin la biblioteca central (cuando incluyo core2.7 da el verifyError), luego funciona. lo que significa que los Métodos y otros contenidos de core 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''