Android java.lang.VerifyError?

В моем приложении для Android я всегда получаю VerifyErrors! И я не могу понять, почему. Всякий раз, когда я включаю внешний JAR, я всегда получаю VerifyErrors при попытке запустить мое приложение (за исключением одного раза, когда я включил Apache Log4j.)

Я обычно обойдусь этим, взяв источник библиотеки и добавив ее в свой проект, но я пытаюсь разместить библиотеку клиентов GData.

Я могу получить это в источнике, но это зависимости (mail.jar, activation.jar, servlet-api.jar) Я не могу, поэтому получаю ошибки проверки. Я хотел бы разобраться в корне этой проблемы раз и навсегда. Я смотрел в Интернете, но все они, кажется, говорят о неполных файлах классов? о котором я не знаю.

Ответ 1

Android использует другой формат файла классов. Вы запускаете сторонние JAR файлы с помощью инструмента "dx", поставляемого с Android SDK?

Ответ 2

Посмотрите на LogCat и посмотрите, что вызывает проверку. Вероятно, это какой-то метод в классе java.lang, который не поддерживается на уровне Android SDK, который вы используете (например, String.isEmpty()).

Ответ 3

От android-developers:

Результат из "adb logcat" указывает класс, который не может быть а также класс, который имеет плохую ссылку. Местоположение идентифицируется вплоть до конкретной инструкции Dalvik. Уловка для просмотра в журналах выше исключения.

Ответ 4

Чтобы сделать это, вам нужно добавить банку библиотеки в одну из исходных папок (даже если вы уже добавили ее в качестве библиотеки eclipse, вам все равно нужно добавить ее в качестве источника).

  • Создайте каталог в своем проекте (e.x. "libs" ) и положить библиотеку jar там.
  • Добавить каталог в класс сборки путь (нажмите правую кнопку на и выберите "Путь сборки" → "Использовать как исходная папка ").
  • Восстановите свой проект.

Ответ 5

Это случилось со мной прямо сейчас. Ошибка была вызвана тем, что я использовал методы из более нового SDK, который был у моего устройства.

Android 1.5 установил apk с помощью этого:

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

Ответ 6

Я нашел интересный случай. Я использую:

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

Таким образом, некоторые из новых возможностей Android 4 не внедряются в Android 2.3, как ImageView.setLayerType. Чтобы избежать ошибки времени выполнения просто:

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

Этот подход должен использоваться также при обработке исключений:

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

NetworkOnMainThreadException не реализован в Android 2.3, поэтому, когда класс загружен (и не раньше!), возникает исключение java.lang.VerifyError.

Ответ 7

Если вы используете Retrolambda, вы могли бы добавить статический метод к интерфейсу (который разрешен только на Java 8).

Ответ 8

Это также может произойти из-за ссылки на предельную ошибку на Lollypop ниже версий, где она ограничена максимальным размером 65K

Возможное решение проблемы выше

Шаг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

Шаг 2. Расширьте приложение с помощью MultiDexApplication, например,

public class MyApplication extends MultiDexApplication

Шаг 3: переопределить attachBaseContext

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

Шаг 4: Следующим шагом будет добавление следующего в часть Android вашего приложения build.gradle

 dexOptions {
      preDexLibraries = false
   }

Шаг 5: Наконец, следуя общей части ваших приложений build.gradle

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

Подробнее, пожалуйста, проверьте

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

Ответ 9

В Eclipse 4.x, если вы столкнулись с этой проблемой, попробуйте выполнить следующее:

  • перенести все включенные 3-сторонние банки в User-Libaray
  • перемещайте пользовательскую библиотеку до андроида и проверяйте ее на вкладке "Заказ и экспорт"
  • очистить и перестроить для запуска

Ответ 10

В моем случае это произошло, когда я обновился от Eclipse Indigo до Eclipse Juno: я не уверен, что является истинной причиной, но мой проект Android, над которым я работаю долгое время, прекратил работу из-за этого исключение.

После многих часов попыток исправить это я нашел решение для меня.

В моем проекте Android я использую другой проект (скажем, "MyUtils" ), который находится в одном рабочем пространстве. Итак, мне нужно было сделать следующее:

Щелкните правой кнопкой мыши на Android-проекте → Путь сборки → Настроить путь сборки

Теперь перейдите на вкладку "Заказ и экспорт" и отметьте "MyUtils". Что это: я избавился от этого досадного исключения.

Ответ 11

Я понижаю версию gradle версии 2.0.0-alpha2 до 1.5.0, которая решила эту проблему.

Ответ 12

Проблема также может быть вызвана несоответствием между двумя проектами андроидов. Например, если вы разработали библиотеку android, используя пакет "com.yourcompany", то у вас есть основной проект приложения, используя тот же пакет, что и базовый пакет. Затем скажем, что вы хотите изменить версию своего основного приложения, поэтому вы изменяете значения файла манифеста: Код версии и имя версии. Если вы запустите свое приложение, не изменяя эти значения для библиотеки, вы получите ошибку проверки при любом вызове метода для объекта из библиотеки.

Ответ 13

У меня была такая же проблема. Я строил с 2.1 r1 и обновлялся до 2.1 r3 с новым адаптером 17. Я проверял ошибки на javamail mail.jar, и это сводило меня с ума. Вот как я решил проблему:

  • создал папку libs/и добавил банки.
  • щелкните правой кнопкой мыши > добавить в качестве исходной папки

Я попробовал перестроить, и он не удался. Я удалил каталог libs/в качестве исходной папки и удалил ссылки на 3 файла jar в пути сборки. Затем я снова добавил папку libs/и добавил каждую банку в папку libs/в путь сборки. Теперь он работает так, как ожидалось. Это странное обходное решение, но это сработало для меня.

Ответ 14

У меня эта проблема после обновления SDK. У компилятора были проблемы с моими внешними библиотеками. Я сделал это: щелкните правой кнопкой мыши на проекте, затем "Инструменты Android > добавьте супер-библиотеку..." эту установку в моей библиотеке проектов "android-support-v4.jar".

Ответ 15

Я тоже получаю VerfiyError... не могу найти настоящую причину. Это помогает обернуть новые строки кода в метод (Eclipse, "Извлечь метод..." ). Поэтому в моем случае причина не является неподдерживаемым методом.

Ответ 16

У меня была очень похожая проблема. Я добавил баны Apache POI, и проблема появилась, когда я обновился до Android SDK 22.3.

У меня были Android Private Libraries, поэтому это была не общая проблема с SDK для Android. Я снял флажки всех Apache POI и добавил один за другим. Я обнаружил, что poi-3.9-20121203.jar должен быть до poi-ooxml-3.9-20121203.jar. В противном случае это не сработает.

Ответ 17

Если у вас есть тесты, попробуйте прокомментировать эту строку из вашего файла build.grade:

testCoverageEnabled = true

Для меня это вызвало исключения VerifyError для классов, в которых используются функции Java 1.7, в частности инструкции для операторов строк.

Ответ 18

У меня была такая же проблема после создания git pull.

Решение: Build → Clean Project.

Надеюсь, что это поможет.

Ответ 19

Я нашел другой случай.

Условия:

  • Используйте Retrolambda (не уверен, что это необходимо);
  • Сделать статический метод в интерфейсе.

И результат - бум! java.lang.VerifyError при попытке доступа к классу, который использует этот интерфейс. Похоже, Android (4.4. * В моем случае) не любит статические методы в интерфейсах. Удаление статического метода из интерфейса позволяет VerifyError уйти.

Ответ 20

java.lang.VerifyError означает, что ваш скомпилированный байт-код ссылается на то, что Android не может найти во время выполнения. Это verifyError Выдает меня только с kitkat4.4 и меньшей версией, не указанной выше в версии, даже если я запустил одну и ту же сборку в обоих устройствах. когда я использовал парсер jsonson 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.+'

Затем я изменил зависимость к последней версии от 2,2 до 2,7 без основной библиотеки (когда я включаю core2.7, он дает verifyError), то он работает, что означает, что методы и другое содержимое core перенесены в последнюю версию Databind2.7. Это исправить мои проблемы.

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

Ответ 21

У меня также была эта проблема, как и мои банки в пользовательской библиотеке...

Как я решил, это добавить их в папку lib, а затем добавить их в свойства сборки в eclipse...

В первый раз, когда я это сделал, это не сработало, но потом я удалил их и снова их прочитал, и он начал работать...

бит странного! но теперь все время работает.

Удача

Ответ 22

Я кодировал методы/класс Android API, которые находятся в SDK 2.1, и пытался запустить его на эмуляторе Android 1.6. Так что я получил эту ошибку.

РЕШЕНИЕ: Изменил его, чтобы исправить версию эмулятора.

ЭТО РАБОТАЕТ ДЛЯ МЕНЯ.. Спасибо.

Ответ 23

Для потомков я просто получил эту ошибку, потому что использовал Arrays.copyOf(), который не является методом, поддерживаемым Java 1.5, который соответствует уровню Android 4. Поскольку я работал, включая библиотеки, разработанные в соответствии с 1.6, они скомпилированы в порядке. Я только видел проблемы, когда я переместил класс, о котором идет речь, в мой проект Android, - тогда ошибка была подсвечена.

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)

В этой строке я пытался сделать new DaoConfigArray, и этот класс имел следующую строку:

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

Что еще более усложнило, так это то, что строка 71 указывала на инициализацию ThreadLocal, которая, как я думал, была причиной проблемы изначально.

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

Ответ 24

Мне пришлось удалять зависимые проекты, а вместо этого компилировать зависимые проекты - jar и включать их в папку libs.

Ответ 25

Я уверен, что моя причина отличалась от вашей, но поскольку это один из лучших хитов при поиске "Android java.lang.VerifyError", я думал, что записал его здесь для потомков.

У меня были классы по строкам:

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

И метод, который сделал:

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

// Fill result
...

Пока этот код присутствовал в файле, я бы получил VerifyError при первом запуске класса, содержащего этот метод. Разделив его на два отдельных метода (один, который касался только B, и тот, который касался только C), устранил проблему.

Ответ 26

В моем случае эта ошибка возникает, потому что моя служба google-play не самая новая.

Если ваш проект не поддерживает какой-либо класс в .jar, эта ошибка возникает (например, ImageView.setLayerType, AdvertisingIdClient и т.д.).

Ответ 27

Я просто определил другую ситуацию, в которой это происходит, причем не только из-за libs, а не dx'ed. У меня есть AsyncTask с очень длинным mehtod doInBackground. По какой-то причине этот метод с более чем 145 линиями начал разрушаться. Это произошло в приложении 2.3. Когда я просто инкапсулировал некоторые части в методы, он работал нормально.

Итак, для тех, кто не смог найти класс, который не был правильно dx'ed, попробуйте уменьшить длину вашего метода.

Ответ 28

Для меня проблема закончилась тем, что я использовал предложение multi-catch где-то в классе, который является функцией Java 7 (и API 19+). Таким образом, он будет разбиваться с VerifyError на всех устройствах до 19.

Ответ 29

Для меня это было в корреляции между compileSdkVersion и buildToolsVersion. У меня было:

compileSdkVersion 21
buildToolsVersion '19.1.0'

Я изменил его на:

compileSdkVersion 21
buildToolsVersion '21.1.2'

Ответ 30

Для меня это проблема compileSdkVersion. Когда я использовал API-уровень 21 в конкретном приложении для Android (https://github.com/android10/Android-AOPExample):

compileSdkVersion 21

произошел java.lang.verifyerror. Поэтому я сменил compileSdkVersion на 19

compileSdkVersion 19

Это сработало. Я думаю, что это может быть проблема SDK buildTools, и кажется ОК, когда уровень API < 21.