Когда ваш проект зависит от артефакта, например com.android.support.*, у вас есть несколько вариантов:
- Если зависимость является транзитивной или поступает из другой библиотеки, вы можете попытаться исключить ее.
Например:
com.some.library: 1.0 -> нужен com.android.support. *
В большинстве случаев все, что нужно от com.android.support, обычно доступен и обратно совместим в соответствующем артефакте androidx. Например: com.android.support.fragment должен работать так же (как минимум), что и его аналог для androidx. (К сожалению, это не всегда случай).
Миграция androidX должна заменить артефакт поддержки соответствующим androidx для вас;см. функцию enable jetifier в официальном руководстве по миграции Android .
Вы по-прежнему можете использовать com.some.library, но вам придется сообщить его exclude библиотеке поддержки (чтобы они не конфликтовали):
например:
implementation ('com.some.library:1.0.0') {
exclude group: 'com.android.support', module: 'appcompat-v7'
exclude group: 'com.android.support', module: 'support-v4'
}
Таким образом, some.library "найдет" свои зависимости, но взятые из ваших артефактов androidx.
Еще одна вещь, которую вы можете сделать, это позволить миграции сделать свое дело и надеяться на лучшее. В большинстве случаев все, что происходит при миграции, - это определить, где вы можете заменить зависимостями androidx, и изменить ваши XML-файлы, импорт Java / Kotlin и т. Д., Чтобы использовать новые. В некоторых случаях инструмент миграции может предлагать проблемы или что-то в этом роде, но я использовал его только пару раз в небольших проектах, поэтому проблемы были очень незначительными, а в некоторых случаях ложноположительными.
Но вкратце, где бы вы ни были, скажем?
<com.android.support.Fragment />
Вам придется заменить на <androidx.Fragment /> (не помнюточный импорт сейчас, но вы поняли).
Вы также должны заменить импорт Java или Kotlin для ссылки на новые классы:
import com.android.support.Fragment
становится
import androidx.fragment.app.Fragment <- этот реальный, я его помню:) </p>
Еще одна вещь, которую делает миграция, - это задействовать проекты "jetifier" и androidx.
Jetifier будет смотреть на ваш код и «заменит» ссылки для вас, даже после того, как вы скомпилировали свой код (или, возможно, он делает это во время компиляции, я не помню), но дело в том,что если библиотека использует ссылку поддержки, она получит для вас androidx-ified. Jetifier был проблематичным, когда он впервые вышел, но к настоящему времени у меня был хороший успех с ним. Поэтому я предлагаю вам попробовать.
Мой последний совет (учитывая, что мне пришлось выполнить эту миграцию support-> androidx в двух проектах среднего размера) - идти медленно, по одной ссылке за раз, собирать и тестироватьстолько, сколько вы можете. И не поддавайтесь искушению обновить все библиотеки одновременно. Это может привести к неожиданным и трудным поискам проблем, которые порождают другие проблемы, которые могут не существовать, если вы решили первую ... короче: будьте медленнее и анализируйте каждую ошибку.
с использованием ./gradlew app:dependencies isтакже хороший способ выяснить, откуда возникает некоторая проблемная зависимость.
Имейте в виду, что некоторые из этих проблем могут возникать, когда вы используете proguard или minify, а не в "отладочных" сборках (из-за конфликта между теми же классами в classpath). Печально известная ошибка "дублированный класс найден ...", среди прочего.
Поэтому всегда старайтесь проверять каждое изменение.
И последнее, но не менее важное, я предлагаю вам не пропускать версии между:
Например: если ваш проект ориентирован на API 26 и вы используете инструменты сборки 26.xx, не пытайтесь перейти на androidX (или попробуйте, но если у вас есть проблемы, откатитесь).
Вместо этого перейдите на Api 28 (например) и инструменты поддержки 28.0.3 (последняя версия поддержкидо androidx). Как только у вас все будет нормально работать, только затем приступайте к испытанию артефактов androidx.
Удачи!