Все мы знаем каким изнурительным бывает процесс поиска проблемы с зависимостями для android.
Как правило в проектах часто используются сторонние third party решения для рекламной медиации, конфигов и атрибуции пользователей
Чаще всего это:
🔸Firebase
🔸IronSource
🔸AppsFlyer
И не менее часто после импортирования в проект одного или нескольких решений, билд перестает успешно собираться. мем 🤣
Безусловно google проделал большую работу, чтобы предоставлять как можно больше информации.
Но есть отдельный сорт проблем, который, как мне кажется, даже с нормальными логами отследить невозможно:
Duplicate class android.support.customtabs.ICustomTabsCallback
found in modules browser-1.4.0-runtime.jar (androidx.browser:browser:1.4.0)
and jetified-androidx.browser.browser-1.0.0-runtime.jar (:androidx.browser.browser-1.0.0:)
И таких примерно 5000 строк
Что это вообще значит?
🔻 Это ошибка в решение графа зависимостей нативных пакетов в android проекте.
У нас есть сборщик maven или gradle, который анализирует проект, берет все версии зависимостей и качает их в проект.
Т.е. IronSource имеет зависимость A, которая требует зависимость B.
А Firebase имеет зависимость B, но другой версии.
И оба пакета используют одно и то же, но разных версий.
При том зависимости есть 3 уровней:
🔹Проект - то что вы указываете в проекте
Мы можем поправить
🔹Пакет - то что указано в импортированном пакете
Мы можем поправить
🔹Компиляция - версии нативных компонентов android
Можем только плакать😭
И вот вы получаете лог в 20МБ в котором тупо список дублирований каждого класса в конфликтных зависимостях.
О том как такое исправлять на youtube никто не выложит. Это скучно, долго и сложно 😴
Дальше я поделюсь процессом, как я решаю подобного рода проблемы:
1️⃣ Импортируем android проект и открываем в android studio
Build -> Android -> Export Project2️⃣ Когда проект без ошибок открывается и синхронизируется, в проекте
UnityLibrary -> build.gradle файлИ комментируем task'у с компиляцией IL2CPP кода — вызов метода
BuildIl2CppТем самым мы сразу экономим кучу времени на компиляции проекта.
3️⃣ По очереди комментируем каждую зависимость, которая прописана в
dependencies и смотрим отключение какой зависимости(-ей) убирает ошибки. Записываем ее в блокнотик.
4️⃣ Переходим на сайт mvnrepository.com и смотрим какие зависимости используются проблемным пакетом
5️⃣ Включив только проблемную зависимость по очереди включаем все зависимости и смотрим с чем конфликтуем
6️⃣ Пытаемся изменить версию пакетов таким образом, чтобы ошибка ушла
Или удаляем один из пакетов 🤷♂️
У меня так было с одной старой зависимостью facebook, 100% там бэкдор от спец. служб 😅
Так же этот процесс можно перенести на сторону unity и сделать resolve зависимостей через EDM4U
Обычно, если есть конфликты, то EDM4U изменит версии пакетов и напишет об этом в консоли.
Что может значительно сократить время на поиск, подсветив конфликтный пакет.
Что еще может помочь:
🔸Перегенерировать все gradle, xml, properties файлы что лежат в Plugins/Android
🔸Ручками скачать зависимости из удаленного репозитория
🔸Переместить их в папку Plugins
🔸Если зависимость типа aar, так же скачать pom файл и прописать все зависимости из него в dependencies внутри build.gradle
🔸Или развернуть собственный maven репозиторий в котором вы поправите версии зависимостей в pom файле
Ну и секретный метод, в случае если ничего не помогло:
Вырываем листик из блокнотика, крепим к кукле-вуду и тыкаем иголкой пока ошибка не уйдет 🤬
На случай если ваш проект после обновления unity перестал собираться, потому что версия gradle была обновлена с версии 4 на 7+, рекомендую держать это пост в сохраненках.
Иначе как у меня пара недель уйдет на сборку и отладку.
Это были заметки с сожженного стула, надеюсь вы никогда с этим не столкнетесь и вам не пригодится этот пост.
А для всех остальных бедолаг, я зарядил этот пост у потомственной бабки шаманки на оберег от проблем с зависимостями уровня компиляции 🫡
Ставь 👍 или оберег не сработает 🤣
#будни@UniArchitect
