verifyerror意味着你编译的字节码指向了Android无法找到的东西。这个verifyError问题我只与kitkat4.4和更低的版本，而不是在上面的版本，即使我在两个设备上运行相同的构建。当我使用老版本的jackson json解析器时，它显示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.+'

然后我将dependency更改为最新版本2.2到2.7，没有核心库，然后它就可以工作了。这意味着core的Methods和其他内容被迁移到Databind2.7的最新版本。这解决了我的问题。

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

生成错误的最小示例

一种简单的方法是使用Jasmin，或者使用二进制文件编辑器手动编辑字节码。

让我们创建一个没有return指令的void方法(由return生成;语句)，jvm认为这是非法的。

在Jasmin中我们可以这样写:

.class public Main
.super java/lang/Object

.method public static main([Ljava/lang/String;)V
   aload_0 ; Just so that we won't get another verify error for empty code.
.end method

然后我们使用javac Main。javap -v Main表示我们已经编译了:

public static void main(java.lang.String[]);
  descriptor: ([Ljava/lang/String;)V
  flags: ACC_PUBLIC, ACC_STATIC
  Code:
    stack=1, locals=1, args_size=1
       0: aload_0

所以实际上没有返回指令。

现在如果我们尝试运行java Main，我们得到:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: (class: NoReturn, method: main signature: ([Ljava/lang/String;)V) Falling off the end of the code
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
        at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
        at java.lang.Class.getMethod0(Class.java:3018)
        at java.lang.Class.getMethod(Class.java:1784)
        at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)

这种错误在Java中通常不会发生，因为Java编译器为我们添加了一个隐式返回void方法。这就是为什么我们不需要在主方法中添加return。你可以用javap检查。

JVMS

当您尝试运行JVMS 7第4.5章指定的某些类型的非法类文件时，将发生VerifyError

jvm说，当Java加载一个文件时，它必须在运行类文件之前运行一系列检查，以确定类文件是OK的。

这样的错误不能在Java代码的一次编译和运行周期中产生，因为JVMS 7 4.10说:

尽管Java编程语言的编译器必须只生成满足所有静态和结构约束的类文件[…] ］

因此，为了查看最小失败示例，我们需要在不使用javac的情况下生成源代码。

verifyerror可能是针对与运行时使用的库不同的库进行编译时的结果。

例如，当我试图运行一个针对Xerces 1编译的程序时，就发生了这种情况，但在类路径中找到了Xerces 2。必需的类(在org.apache中)。* namespace)在运行时被发现，所以ClassNotFoundException不是结果。对类和方法进行了更改，因此在运行时发现的方法签名与编译时的方法签名不匹配。

通常，编译器会在方法签名不匹配的地方标记问题。当类加载时，JVM将再次验证字节码，并在字节码试图做一些不应该被允许的事情时抛出VerifyError——例如，调用一个返回String的方法，然后将返回值存储在一个包含List的字段中。

使用JRE > 6的CGLIB < 2.2可能会触发类似的错误，请参见“我应该升级到CGLIB 3.0吗?”和Spring sprr -9669上的一些评论。

当在JRE 6上一切工作正常，而仅仅切换到JRE7就会出现问题时，这一点尤其正确。

正如Kevin Panko所说，这主要是因为图书馆的变化。 因此，在某些情况下，“清理”项目(目录)，然后进行构建就可以了。

在Android Studio 3.6.1中更新Gradle后，在发布版本的API 19上发生了崩溃。

有一个格莱德库错误。解决方法是重写proguard-rules.txt。

降级Gradle也可以(类路径为'com.android.tools.build: Gradle:3.5.3')，但这是一个过时的解决方案，不要使用它。