Android java.lang.VerifyError?




gdata (20)

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.

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


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?


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


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

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


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

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í, 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'

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.


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





verifyerror