Я строил проект в gitlab ci
./gradlew assembleDebug --stacktrace
и иногда это порождает ошибку:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:transformClassesWithDexBuilderForDebug'.
> com.android.build.api.transform.TransformException: java.lang.IllegalStateException: Dex archives: setting .DEX extension only for .CLASS files
На моем локальном компьютере он работает правильно.
версия kotlin - 1,2
multidex включен
В чем причина этой ошибки?
Кажется, я нашел решение. В момент сборки град показывал предупреждения для меня:
Configuration 'compile' in project ':app' is deprecated. Use 'implementation' instead.
app: 'androidProcessor' dependencies won't be recognized as kapt annotation processors. Please change the configuration name to 'kapt' for these artifacts: 'com.arello-mobile:moxy-compiler:1.5.3' and apply the kapt plugin: "apply plugin: 'kotlin-kapt'".
Я сделал орфографию и забыл удалить ненужную аннотациюПроцессор для библиотеки:
annotationProcessor "com.arello-mobile:moxy-compiler:$moxyVersion"
kapt "com.arello-mobile:moxy-compiler:$moxyVersion"
Поэтому я удалил первую строку.
После этого я применил плагин kapt, apply plugin: 'kotlin-kapt' и исправил некоторые ошибки сборки в коде после него.
В конце концов я понял, что забыл заменить compile на implementation в некоторых местах. Странно, но без него сборка не сработала.
Это изменяет исправление моей сборки ошибок.
./gradlew clean исправил ту же ошибку для меня.
Для разработчиков Cordova,
Если вы получили эту ошибку сборки в своем проекте, как сказал Pierrick Martellière в комментариях к этому ответу, в папке вашего проекта используйте:
cordova clean
Это делает очистку и сборку сразу
Выше ответ в основном правильный, но в моем случае я получаю это исключение, когда я клачу одноименное имя java и kotlin file, а затем удаляет один из них.
Решения: просто Build → Clean Project мой проект, и он работает. И мой проект также включил multiDex.
defaultConfig {
...
// Enabling multidex support.
multiDexEnabled true
}
Как упоминалось выше, чистка @mixel выполняет свою работу. Но, как вариант не делать это вручную, просто добавьте "чистую" задачу градиента в конфигурацию приложения, чтобы она выполнялась все время перед запуском. Конечно, это может замедлить весь процесс.
Настройка для multidexing не решила эту проблему для меня.
Однако я придумал резолюцию... своего рода. В основном это связано с созданием запроса на перенос для второй ветки на том же самом фиксации, что и сбой сборки. Конструкция для этого запроса на растяжение прошла успешно, а затем Битбукет подумал, что исходный запрос на изгиб был в порядке и позволил нам объединиться, хотя мы не внесли никаких изменений в эту ветку. Там есть какая-то необъяснимая странность, но техника работает.
Вот как я это сделал:
Предположим, что ветвь, которая терпит неудачу, называется bad-branch.
Я создал новую ветку с именем bad-branch-copy на коммите, которая была распространена между bad-branch и develop. Затем я слил bad-branch в bad-branch-copy. Конечным результатом этого была быстрая перемотка вперед, так что bad-branch-copy оказалась на той же фиксации, что и bad-branch. Я ожидал отдельной фиксации, поэтому этот результат меня удивил, но я все равно хватался за соломинку, поэтому продолжал идти.
Затем я подтолкнул bad-branch-copy к GitHub и создал запрос на извлечение из bad-branch-copy для develop. Это вызвало сборку на bad-branch-copy → develop, которая была успешной.
В этот момент buddybuild продемонстрировал успешное построение на bad-branch-copy → develop и все еще показал неудачу на bad-branch → develop. Тем не менее, Bitbucket продемонстрировал успешную сборку на запрос тяги для bad-branch. Да, это право: buddybuild показал неудачу, но Битбукет сказал, что все в порядке.
Тогда мы смогли объединить запрос с bad-branch ветром, и все было хорошо с миром. Пожалуйста, не спрашивайте меня, почему я не буду отвечать. :)
Я думаю, что то же самое можно было бы сделать с помощью
git checkout bad-build
git checkout -b bad-build-copy
git push origin bad-build-copy
после чего создается запрос на извлечение для плохой сборки.
Я смог решить проблему, закрыв и перезапустив Android Studio. Возможно, даже проект Rebuild также сделал бы это (не пытался, хотя).
В настоящее время с помощью Android Studio 3.3.2 я просто отключил мгновенный запуск, и он заработал.
То, что решило проблему для меня, вручную добавило все конфликтующие файлы. Например, в моем файле Gradle у меня было:
implementation 'com.android.support:support-compat:27.1.1'
это было подчеркнуто красным. Я завис над линией, и студия android сказала, что возник конфликт с другим файлом, использующим более низкую версию. Ошибка была похожа на
come.android.support:support-annotations:26.0.1 конфликтует/смешивает версии с 27.1.1.
Он дал мне имена файлов, и я вручную добавил их с соответствующей версией, чтобы они все соответствовали
compile 'com.android.support:support-annotations:27.1.1'
compile 'com.android.support:support-compat:27.1.1'
compile 'com.android.support:support-core-ui:27.1.1'
compile 'com.android.support:animated-vector-drawable:27.1.1'
compile 'com.android.support:appcompat-v7:27.1.1'
compile 'com.android.support:design:27.1.1'
Ни одно из существующих решений не помогло мне, и это было исправлено простым отключением Instant Run.
Простое решение
Для ионных и кордовских проектов
cordova clean
пожалуйста, найдите здесь решение этой проблемы,
defaultConfig {
...
minSdkVersion 14
targetSdkVersion 21
...
// Enabling multidex support.
multiDexEnabled true
}
dependencies {
compile 'com.android.support:multidex:1.0.0'
}