Android java.lang.VerifyError?

Question

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.

Jamshid

GData is known not to work in Android. Search for the topic in the android-developers Google Group. We need to wait for an official GData for Android, in a future SDK release. – Figurine

Are you using Gradle to build your project? I had this problem when I forgot to run the clean task before assembleRelease task... – Elboa

Answer 1

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?

Madison

Would be awsome with some more info on the "dx" tool. – Palladian

Look in the "Library" section of the Android project preferences, below the list of SDK versions. Do your external projects you're relying on in your build show up there, with a green tick next to them? – Finnougrian

@Finnougrian THANK YOU for that comment! You just solved a problem I spent way too much time trying to figure out. – Compost

Answer 2

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

Palmar

This should be marked as real answer. At least what it was exactly in my case since I was getting sporadic errors from my users and I tracked it down to View.getTag(int) call that is not supported in v. 3 of API – Silvanasilvano

Agreed. I have encountered this a few times and each time it's that I'm targeting 2.x and using something that's not in 1.5. What throws you off is it's thrown when the class is created/used for the first time only, so if it's something that happens sporadically you might not notice it for a while. – Cleliaclellan

If this is the case, you should checkout these links: developer.android.com/resources/articles/… and doandroids.com/blogs/2010/5/8/backwards-compatibility – Pleistocene

"This should be marked as real answer." I came accross this thread because I have the same problem. I'm guessing the reason why this was not marked as the real answer is because LogCat gives a line reference to where I am making an instance of a library but not the line where the problem is caused. In other words, in this case LogCat is near useless. – Mythopoeic

logcat at WARN level should show you the details on why it failed verify – Acuff

Answer 3

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.

Congregationalist

Looking above the exception helped me, too, to identify the method that was causing the error. For me, it was the expression Build.VERSION.SDK_INT >= Build.VERSION_CODES.ECLAIR which is kinda obvious, in the end, if you try that on Cupcake... – Ecclesiolatry

Thanks! This was the problem I was getting... the useful logs were just above the exception: WARN/dalvikvm(1052): VFY: unable to resolve static method 475: Ljavax/xml/datatype/DatatypeFactory;.newInstance ()Ljavax/xml/datatype/DatatypeFactory; (now to figure out how to do without DatatypeFactory) – Sputter

Looking above the error helped me also. Look for a message that starts with "VFY:" In my case, it said "arbitrarily rejecting large method". Probably because it creates a huge number of arrays :) anyways, thanks for the tip! – Swacked

Thanks! I found my problem was on the exception handler: NetworkOnMainThreadException is not implemented in Android 2.3. Look down for my reply. Thanks again! :) – Hebbe

Thanks! In my case, I was targeting Android2.3 and I was using the android-support-v4.jar, and it was not finding the classes in this jar. I had to click on the "export" tab for this class in the properties and bring it above the android2.3.3 library. Well, this export is really something I don't understand clearly... – Resistor

The trick "look in the logs above the exception" helps a lot. Thank you! In my case, it points to a specific class of an Android support library. – Debauchery

Answer 4

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.

Motoneuron

Can we add a "Project Library" instead of a JAR to the 'libs' folder? – Hadwin

Strange... I had to add it as a normal Java library - not as a library under the "Android" menu in Eclipse. – Ecdysis

Answer 5

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

Squireen

Answer 6

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.

Uninstructed

The same happened with me. I used java.lang.ReflectiveOperationException which is not included in older Android versions (for example 4.2), but Lint did not warned me about this... – Boxboard

For me the problem is my code declare a CameraAccessException, which is introduced at Android 5.0, but when I run in an Android 4.3 device, the VerifyError is thrown. – Diandiana

Answer 7

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

Cavy

Answer 8

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

Cuss

Worked for me!! don't forget to change Application class to "MultiDexApplication". – Hillaryhillbilly

You saved me big time man. This should be the accepted answer. – Endotoxin

Answer 9

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.

Chiang

That's what fixed it for me... we have a large project so I went around and just checked the "export" flag on everything. PITA issue. – Janie

Answer 10

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

Worthless

Answer 11

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.

Northeaster

Answer 12

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.

Prosecute

Answer 13

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

Failing

Answer 14

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

Gaddis

Answer 15

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'

Db

Answer 16

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.

Ferine

Answer 17

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.

Comate

Answer 18

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.

Acre

Answer 19

I had the same problem after making a git pull.

Solution: Build -> Clean Project.

Hope this helps.

Gastronomy

Didn't pull or do anything really, but a clean did it, thanks! – Gennie

Answer 20

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.

Timberlake

Answer 21

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

Aquilar

Answer 22

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.

Monazite

Answer 23

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();
    }
};

Dunlop

Answer 24

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

Kalikalian

Answer 25

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.

Waterresistant

And, by the way, the way I root-caused it was commenting out method bodies (replacing with return null/0/false) until the VerifyError went away, then restoring stuff until it came back again; then doing the same within the problem method. Not a fun way to debug, certainly, but it worked. – Waterresistant

Answer 26

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

Paramagnet

Answer 27

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.

Frolic

Answer 28

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.

Commutative

Answer 29

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'

Congenital

Answer 30

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.

Destinee