Ответ 1
Android использует другой формат файла классов. Вы запускаете сторонние JAR файлы с помощью инструмента "dx", поставляемого с Android SDK?
В моем приложении для Android я всегда получаю VerifyErrors! И я не могу понять, почему. Всякий раз, когда я включаю внешний JAR, я всегда получаю VerifyErrors при попытке запустить мое приложение (за исключением одного раза, когда я включил Apache Log4j.)
Я обычно обойдусь этим, взяв источник библиотеки и добавив ее в свой проект, но я пытаюсь разместить библиотеку клиентов GData.
Я могу получить это в источнике, но это зависимости (mail.jar, activation.jar, servlet-api.jar) Я не могу, поэтому получаю ошибки проверки. Я хотел бы разобраться в корне этой проблемы раз и навсегда. Я смотрел в Интернете, но все они, кажется, говорят о неполных файлах классов? о котором я не знаю.
Android использует другой формат файла классов. Вы запускаете сторонние JAR файлы с помощью инструмента "dx", поставляемого с Android SDK?
Посмотрите на LogCat и посмотрите, что вызывает проверку. Вероятно, это какой-то метод в классе java.lang, который не поддерживается на уровне Android SDK, который вы используете (например, String.isEmpty()).
Результат из "adb logcat" указывает класс, который не может быть а также класс, который имеет плохую ссылку. Местоположение идентифицируется вплоть до конкретной инструкции Dalvik. Уловка для просмотра в журналах выше исключения.
Чтобы сделать это, вам нужно добавить банку библиотеки в одну из исходных папок (даже если вы уже добавили ее в качестве библиотеки eclipse, вам все равно нужно добавить ее в качестве источника).
Это случилось со мной прямо сейчас. Ошибка была вызвана тем, что я использовал методы из более нового 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 ниже версий, где она ограничена максимальным размером 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'
}
}
}
Подробнее, пожалуйста, проверьте
В Eclipse 4.x
, если вы столкнулись с этой проблемой, попробуйте выполнить следующее:
В моем случае это произошло, когда я обновился от Eclipse Indigo до Eclipse Juno: я не уверен, что является истинной причиной, но мой проект Android, над которым я работаю долгое время, прекратил работу из-за этого исключение.
После многих часов попыток исправить это я нашел решение для меня.
В моем проекте Android я использую другой проект (скажем, "MyUtils" ), который находится в одном рабочем пространстве. Итак, мне нужно было сделать следующее:
Щелкните правой кнопкой мыши на Android-проекте → Путь сборки → Настроить путь сборки
Теперь перейдите на вкладку "Заказ и экспорт" и отметьте "MyUtils". Что это: я избавился от этого досадного исключения.
Я понижаю версию gradle версии 2.0.0-alpha2 до 1.5.0, которая решила эту проблему.
Проблема также может быть вызвана несоответствием между двумя проектами андроидов. Например, если вы разработали библиотеку android, используя пакет "com.yourcompany", то у вас есть основной проект приложения, используя тот же пакет, что и базовый пакет. Затем скажем, что вы хотите изменить версию своего основного приложения, поэтому вы изменяете значения файла манифеста: Код версии и имя версии. Если вы запустите свое приложение, не изменяя эти значения для библиотеки, вы получите ошибку проверки при любом вызове метода для объекта из библиотеки.
У меня была такая же проблема. Я строил с 2.1 r1 и обновлялся до 2.1 r3 с новым адаптером 17. Я проверял ошибки на javamail mail.jar, и это сводило меня с ума. Вот как я решил проблему:
Я попробовал перестроить, и он не удался. Я удалил каталог libs/в качестве исходной папки и удалил ссылки на 3 файла jar в пути сборки. Затем я снова добавил папку libs/и добавил каждую банку в папку libs/в путь сборки. Теперь он работает так, как ожидалось. Это странное обходное решение, но это сработало для меня.
У меня эта проблема после обновления SDK. У компилятора были проблемы с моими внешними библиотеками. Я сделал это: щелкните правой кнопкой мыши на проекте, затем "Инструменты Android > добавьте супер-библиотеку..." эту установку в моей библиотеке проектов "android-support-v4.jar".
Я тоже получаю VerfiyError... не могу найти настоящую причину. Это помогает обернуть новые строки кода в метод (Eclipse, "Извлечь метод..." ). Поэтому в моем случае причина не является неподдерживаемым методом.
У меня была очень похожая проблема. Я добавил баны Apache POI, и проблема появилась, когда я обновился до Android SDK 22.3.
У меня были Android Private Libraries, поэтому это была не общая проблема с SDK для Android. Я снял флажки всех Apache POI и добавил один за другим. Я обнаружил, что poi-3.9-20121203.jar должен быть до poi-ooxml-3.9-20121203.jar. В противном случае это не сработает.
Если у вас есть тесты, попробуйте прокомментировать эту строку из вашего файла build.grade
:
testCoverageEnabled = true
Для меня это вызвало исключения VerifyError для классов, в которых используются функции Java 1.7, в частности инструкции для операторов строк.
У меня была такая же проблема после создания git pull.
Решение: Build → Clean Project.
Надеюсь, что это поможет.
Я нашел другой случай.
Условия:
И результат - бум! java.lang.VerifyError при попытке доступа к классу, который использует этот интерфейс. Похоже, Android (4.4. * В моем случае) не любит статические методы в интерфейсах. Удаление статического метода из интерфейса позволяет VerifyError уйти.
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'
У меня также была эта проблема, как и мои банки в пользовательской библиотеке...
Как я решил, это добавить их в папку 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 и т.д.).
Я просто определил другую ситуацию, в которой это происходит, причем не только из-за libs, а не dx'ed. У меня есть AsyncTask с очень длинным mehtod doInBackground. По какой-то причине этот метод с более чем 145 линиями начал разрушаться. Это произошло в приложении 2.3. Когда я просто инкапсулировал некоторые части в методы, он работал нормально.
Итак, для тех, кто не смог найти класс, который не был правильно dx'ed, попробуйте уменьшить длину вашего метода.
Для меня проблема закончилась тем, что я использовал предложение 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.