Вопрос

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

Обычно я обходлю это, беря исходный код библиотеки и добавляя его в свой проект, но я пытаюсь поместить Клиентская библиотека GData.

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

Это было полезно?

Решение

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

Другие советы

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

От android-разработчики:

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

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

  1. Создайте каталог в своем проекте (например.x."библиотеки") и поместите туда библиотечную банку .
  2. Добавьте каталог в класс сборки по пути (нажмите правую кнопку мыши на папке и выберите "Путь сборки" -> "Использовать в качестве исходной папки").
  3. Перестройте свой проект.

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

Устройство Android 1.5 установило apk-файл, используя это:

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

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

<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 происходит.

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

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

Возможное решение вышеуказанной проблемы

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

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

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

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

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

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

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

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

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

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

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

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

  1. перенесите все включенные сторонние jar-файлы в пользовательскую библиотеку
  2. переместите пользовательскую библиотеку перед библиотекой Android и отметьте ее на вкладке Порядок и экспорт
  3. очистите и перестройте для запуска

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

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

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

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

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

testCoverageEnabled = true

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

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

Решение:Сборка -> Очистить проект.

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

Я нашел еще одно дело.

Условия:

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

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

java.lang.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.+'

Затем я изменил Зависимость на последняя версия 2.2 - 2.7 без основная библиотека(когда я включаю core2.7, это выдает VerifyError), тогда это работает.что означает Методы и другое содержание Ядро перенесен на последнюю версию База данных 2.7.Это исправит мои Проблемы.

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

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

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

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

немного странный случай!но теперь работаю все время.

Удачи вам

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

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

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

Для потомков, я просто получил эту ошибку, потому что я использовал 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();
    }
};

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

Я уверен, что моя причина отличалась от вашей, но поскольку это один из лучших хитов при поиске "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) устранило проблему.

В моем случае эта ошибка возникает из-за того, что мой google-play-сервис не самый новый.

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

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

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

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

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

compileSdkVersion 21
buildToolsVersion '19.1.0'

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

compileSdkVersion 21
buildToolsVersion '21.1.2'

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

compileSdkVersion 21

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

compileSdkVersion 19

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top