Android java.lang.VerifyError?

JavaAndroidGdataVerifyerror

Java Problem Overview


In my Android app, I always get VerifyErrors! And I cannot figure out why. Whenever I include a external JAR, I always get VerifyErrors when I try to launch my app (except for once, when I included Apache Log4j.)

I usually get around this by taking the source of the library and adding it to my project, but I am trying to put the GData client library.

I can get this in source, but it's dependencies (mail.jar, activation.jar, servlet-api.jar) I cannot, so I get verify errors. I would like to get to the root of this problem once and for all. I looked on the internet, but they all seem to talk about incomplete class files? which I do not know of.

Java Solutions


Solution 1 - Java

Look at LogCat and see what's causing the verifyerror. It's probably some method in a java.lang class that is not supported on the android SDK level you are using (for instance, String.isEmpty()).

Solution 2 - Java

From android-developers:

The output from "adb logcat" indicates the class that could not be found as well as the class that has the bad reference. The location is identified down to the specific Dalvik instruction. The trick is to look in the logs above the exception.

Solution 3 - Java

Android uses a different class file format. Are you running the 3rd party JAR files through the "dx" tool that ships with the Android SDK?

Solution 4 - Java

To make it work you need to add jar of the library to one of the source folders (even if you have already added it as eclipse library, you still need to add it as source).

  1. Create a directory in your project (e.x. "libs") and put library jar there.
  2. Add the directory to the build class path by (click right button on the folder and select "Build path"->"Use as source folder").
  3. Rebuild your project.

Solution 5 - Java

It happened to me right now. The error was caused because I was using methods from a newer SDK that my device had.

Android 1.5 device installed an apk using this:

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

Solution 6 - Java

I found an interesting case. I use:

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

So some of new Android 4 capabilities are not implenented in Android 2.3 like ImageView.setLayerType. To avoid runtime error simply:

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

This approach should be used also with exceptions handling:

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

NetworkOnMainThreadException is not implemented in Android 2.3 so when the class is loaded (and not before!) the exception java.lang.VerifyError occurs.

Solution 7 - Java

If you're using Retrolambda you might have added a static method to an interface (which is only allowed in Java 8).

Solution 8 - Java

This can also occur because of referencing limit error on Lollypop below versions, where it is limited upto max 65K size

Possible solution for above issue

Step1: 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

Step2: Extend your application with MultiDexApplication, for e.g.

public class MyApplication extends MultiDexApplication

Step3: Override attachBaseContext

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

Step4: The next step is to add the following to the android part of your apps build.gradle

 dexOptions {
      preDexLibraries = false
   }

Step5: Lastly, following to the general part of your apps build.gradle

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

For details, please checkout

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

Solution 9 - Java

In my case, it happened when I updated from Eclipse Indigo to Eclipse Juno: I'm not sure what is the true reason, but, my Android project that I'm working on for a long time stopped work because of that exception.

After many hours of trying to fix that, I found the solution for me.

In my Android project, I use other project (say, "MyUtils") that is in the same workspace. So, I needed to do the following:

Right click on Android project -> Build path -> Configure build path

Now, go to tab "Order and Export" and make "MyUtils" checked. That's it: I got rid of this annoying exception.

Solution 10 - Java

I downgrade gradle version from 2.0.0-alpha2 to 1.5.0 that solved this problem.

Solution 11 - Java

The problem could also be caused by a mismatch between two androids projects. For example if you have developed an android library using the package "com.yourcompany", Then you have the main application's project using the same package as base package. Then let say you want to change the version of your main app, so you change the manifest file's values: Version Code and Version name. If you run your app without changing those values for the library, you would get a verify error on any call of a method on a object from the library.

Solution 12 - Java

I had the same issue. I was building with 2.1 r1 and updated to 2.1 r3 with the new adt 17. I had verify errors on javamail's mail.jar and it was driving me crazy. Here is how i solved the issue:

  1. created a libs/ folder and added the jars.
  2. right click > add as source folder

i tried a rebuild and it failed. I removed the libs/ directory as a source folder and removed refs to the 3 jar files in the build path. Then i added the libs/ folder again, and added each jar in the libs/ folder to the build path. Now it works as expected. This is a weird workaround but it worked for me.

Solution 13 - Java

In Eclipse 4.x, if you encounter this problem, try below:

  1. migrate all included 3th-party jars into the User-Libaray
  2. move up the user lib before the android lib and check it in the Order and Export tab
  3. clean and rebuild to run

Solution 14 - Java

I have this issue after a SDK update. The compiler had problems with my external librarys. I did this: right click on project, then "android Tools > add suport library..." this install on my project library "android-support-v4.jar".

Solution 15 - Java

java.lang.VerifyError means your compiled bytecode is referring to something that Android cannot find at runtime. This verifyError Issues me only with kitkat4.4 and lesser version not in above version of that even I ran the same build in both Devices. when I used jackson json parser of older version it shows 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.+'

Then I have changed the Dependancy to the latest version 2.2 to 2.7 without the core library(when I include core2.7 it gives the verifyError), then it works. which means the Methods and other contents of core is migrated to the latest version of Databind2.7. This fix my Issues.

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

Solution 16 - Java

I get the VerfiyError as well... can't find a real reason. It helps to wrap the new lines of code into a method (Eclipse, 'Extract Method...'). So in my case the reason is not an unsupported method.

Solution 17 - Java

I had very similar problem. I had added Apache POI jars and problem appeared when I updated to android SDK 22.3.

I had Android Private Libraries checked so this was not the common problem with android SDK. I unchecked all Apache POI jars and added one by one. I found that poi-3.9-20121203.jar should be before poi-ooxml-3.9-20121203.jar. Otherwise it will not work.

Solution 18 - Java

If you have tests, try commenting out this line from your build.grade file:

testCoverageEnabled = true

For me this caused VerifyError exceptions on classes which use Java 1.7 features, particularly string switch statements.

Solution 19 - Java

I had the same problem after making a git pull.

Solution: Build -> Clean Project.

Hope this helps.

Solution 20 - Java

I have found another case.

Conditions:

  • Use Retrolambda (not sure if it's necessary);
  • Make a static method in an interface.

And the result is boom! java.lang.VerifyError when trying to access the class that uses that interface. Looks like Android (4.4.* in my case) doesn't like static methods in interfaces. Removing the static method from interface makes VerifyError go away.

Solution 21 - Java

I also had this problem, as had my jars in a user library...

The way I solved this was to add them to the lib folder and then add them in the build properties in eclipse...

The first time i did this it did not work, but then i removed them and readded them again and it started working...

bit of a strange one! but now working all the time.

Good Luck

Solution 22 - Java

I have coded Android API methods/class that are in SDK 2.1, and was trying to run it on Android 1.6 emulator. So i got that error.

SOLUTION: Changed it to correct emulator version.

THIS WORKED FOR ME.. Thanks.

Solution 23 - Java

For posterity, I just got this error because I was using Arrays.copyOf() which is not a method supported by Java 1.5 which corresponds to Android Level 4. Because I was running including libraries developed under 1.6 they compiled fine. I only saw the problems when I moved the class in question over to my Android project -- then the error was highlighted.

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)

On that line I was trying to do a new DaoConfigArray and that class had the following line:

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

What made it even more complicated is that line 71 was pointing to a ThreadLocal initialization which I thought was the reason for the problem initially.

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

Solution 24 - Java

I had to remove dependent projects and instead compile dependent projects are jar's and include them in the libs folder.

Solution 25 - Java

I'm sure that my cause was different than yours, but since this is one of the top hits when searching for "Android java.lang.VerifyError", I thought I'd record it here for posterity.

I had some classes along the lines of:

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

And a method that did:

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

// Fill result
...

As long as this code was present in the file, I would get a VerifyError the first time the class containing this method was loaded. Splitting it out into two separate methods (one that dealt only with B's, and one that dealt only with C's) fixed the problem.

Solution 26 - Java

In my case, this error occur because my google-play-service is not the newest.

If your project does not support some class in the .jar, this error occurs(ex. ImageView.setLayerType, AdvertisingIdClient, etc.).

Solution 27 - Java

I just identified another situation that it occurs, not only due to libs not dx'ed. I have a AsyncTask with a very long doInBackground mehtod. For some reason this method with more than 145 lines started to break. It happened on a 2.3 app. When I just encapsulated some parts into methods, it worked fine.

So for those that could not find the class that was not correctly dx'ed, try reducing the length of your method.

Solution 28 - Java

For me, the issue ended up actually being that I was using multi-catch clause somewhere in the class which is a Java 7 feature (and API 19+). So it would crash with VerifyError on all pre-19 devices.

Solution 29 - Java

For me it was in correlation between compileSdkVersion and buildToolsVersion. I had:

compileSdkVersion 21
buildToolsVersion '19.1.0'

I changed it to:

compileSdkVersion 21
buildToolsVersion '21.1.2'

Solution 30 - Java

For me, it is the problem of compileSdkVersion. When I used the API level 21 in a specific android application (https://github.com/android10/Android-AOPExample):

compileSdkVersion 21

the java.lang.verifyerror happened. So I changed the compileSdkVersion to 19

compileSdkVersion 19

It worked well. I think that it might be the problem of SDK buildTools, and it seems OK when API level < 21.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionIsaac WallerView Question on Stackoverflow
Solution 1 - JavaAlexView Answer on Stackoverflow
Solution 2 - JavaADBView Answer on Stackoverflow
Solution 3 - JavaTofuBeerView Answer on Stackoverflow
Solution 4 - JavaMaksim GolivkinView Answer on Stackoverflow
Solution 5 - JavaMacarseView Answer on Stackoverflow
Solution 6 - JavaSeraphim'sView Answer on Stackoverflow
Solution 7 - JavaTakhionView Answer on Stackoverflow
Solution 8 - JavaPawan MaheshwariView Answer on Stackoverflow
Solution 9 - JavaDmitry FrankView Answer on Stackoverflow
Solution 10 - JavaSun ZhengchangView Answer on Stackoverflow
Solution 11 - JavaZeroOneView Answer on Stackoverflow
Solution 12 - JavaThumbsDPView Answer on Stackoverflow
Solution 13 - Javauser1691964View Answer on Stackoverflow
Solution 14 - JavaAndreuView Answer on Stackoverflow
Solution 15 - Javaanand krishView Answer on Stackoverflow
Solution 16 - Javaasdf werView Answer on Stackoverflow
Solution 17 - JavaGrzegorz BielańskiView Answer on Stackoverflow
Solution 18 - JavaaluxianView Answer on Stackoverflow
Solution 19 - JavaVingtoftView Answer on Stackoverflow
Solution 20 - JavaDisplay NameView Answer on Stackoverflow
Solution 21 - JavaBenjamin LambeView Answer on Stackoverflow
Solution 22 - JavaPiyush PatelView Answer on Stackoverflow
Solution 23 - JavaGrayView Answer on Stackoverflow
Solution 24 - JavaSiddharthView Answer on Stackoverflow
Solution 25 - JavabenkcView Answer on Stackoverflow
Solution 26 - JavaAllenView Answer on Stackoverflow
Solution 27 - JavaRafael CoutinhoView Answer on Stackoverflow
Solution 28 - JavaJinView Answer on Stackoverflow
Solution 29 - JavagingoView Answer on Stackoverflow
Solution 30 - JavalilinView Answer on Stackoverflow