Android useandroidx true android enablejetifier true

Переходим на Androidx или увлекательное путешествие по граблям

Тема перехода на Androidx сейчас витает в воздухе. Уже есть коротенькая статья на английском от Daniel Lew, есть доклад. Но все они довольно поверхностно рассматривают сценарий перехода описанный в документации Google.

Я же хочу поделиться своим опытом. В моем проекте используются Moxy и Cicerone, считаю свой опыт интересным, потому что в официальных телеграмм-каналах этих библиотек периодически всплывает вопрос, когда же они будут переведены на Androidx.

Just Migrate to AndroidX.

Для того чтобы перевести проект на Androidx нужно выполнить несколько простых шагов:

1. Установить compileSdkVersion 28 и targetSdkVersion 28, обновить все саппорт-библиотеки до последних версий.

2. В файле gradle.properties добавить строки:

3. Если вы уже используете Android Studio 3.2 то воспользуйтесь рефакторингом:

Он сделает для вас большую (или меньшую) часть работы.

Если вы, по какой-то причине не используете Git, или другую систему контроля версий, то на этом этапе у вас будет шанс сделать архив проекта:

Жмем кнопку Migrate, выбираем куда сохранять архив, и через некоторое время, получаем результат проверки проекта перед рефакторингом:

Здесь мы видим, какие зависимости в build.gradle и в директивах импорта будут заменены. На примере класса MainActivity, как можно видеть на скриншоте выше, будет заменена одна зависимость: android.support.v4.view.GravityCompat, но, если мы откроем этот класс, то увидим, что фактически там есть еще три зависимости которые надо заменить:

Я не понял, в чем причина такого избирательного поведения, но эти зависимости придется исправлять вручную. Жмем «Do Refactor».

Надо будет изменить зависимости в build.gradle (для наглядности я закомментировал старые зависимости):

С полным списком замен можно ознакомиться здесь.

Затем выполните синхронизацию проекта с Gradle, и получите кучу ошибок. Это директивы импорта в ваших классах, ссылаются на старые пакеты, нужно их поменять в соответствии с этой таблицей.

Итак, поскольку студия не смогла заменить все зависимости (возможно у вас смогла, тогда вас можно поздравить), при попытке собрать проект, вы увидите похожий список ошибок:

Открыв класс с ошибками, мы увидим примерно такую картину:

Удаляем устаревшие зависимости, и по хоткею Alt+Enter импортируем классы из пакета androidx

Таким образом исправляем все классы. Если ошибка не связана с «импортом», не обращайте на неё внимание, скорее всего она из-за тех же проблем в другом классе.

Здесь ошибки связаны с тем, что в классе TimelineView тоже нужно устранить проблемы с импортом. Когда все ошибки будут исправлены, снова выполняем билд проекта, и возможно, снова получаем список ошибок, только уже в других классах, процесс итеративно продолжаем.

На ошибки с классами, которые генерируются (Dagger или DataBinding), на этом этапе не обращайте внимания. Если ошибок в ваших классах не осталось, а студия ругается только на генерированный код, то нужно выполнить Clean Project и Rebuild Project.

Если это не помогает, можно попробовать очистить кэш студии:

Очистить кэш вам придется, как минимум один раз, чтобы корректно создались классы которые генерируют DataBinding или Room.

Внешние библиотеки

Вообще, флаг android.enableJetifier=true мы устанавливали как раз для того, чтобы на этапе сборки проекта, зависимости внешних библиотек подменялись на соответствующие зависимости AndroidX автоматически, но, у меня этого почему-то не происходит.

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

MainActivity в моем проекте наследуется от MvpAppCompatActivity это класс Moxy, которая, на момент написания статьи, еще не переведена на AndroidX. Чтобы решить эту проблему, я скопировал класс к себе в проект, в отдельный пакет androidx, и исправил зависимости в нем. Имя класса лучше оставить без изменений, так будет проще обновлять зависимости.

Ту же процедуру нужно проделать и для фрагментов, для класса MvpAppCompatFragment.

Обратите внимание, что в этих классах есть дженерик, в поле mMvpDelegate, не забудьте поправить зависимость в нем, её легко не заметить, потому что это зависимость от класса Moxy, а не от класса саппорт-библиотеки.

Cicerone

Для решения проблем с Cicerone мне пришлось создать у себя в проекте копию класса SupportAppScreen и SupportAppNavigator. Обратите внимание, что класс SupportAppNavigator зависит от SupportAppScreen. Не забудьте исправить эту зависимость на свою копию.

Источник

Converting your Android App to Jetpack

Google has rebranded their support libraries to be named Jetpack (aka AndroidX). Developers will need to make changes to account for this.

This article will explain what this means, and how to get started converting your project to use the new components.

What is Jetpack?

Android Jetpack is a set of libraries, tools and architectural guidance that is designed to make it easy to build Android apps. It is intended to provide common infrastructure code so the developer can focus on writing things that make an app unique.

It is a large scope effort to improve developer experience and collect useful tools and frameworks into a cohesive unit.

This quote from Alan Viverette (Android Framework team) is a good summary:

“Jetpack is a larger-scoped effort to improve developer experience, but AndroidX forms the technical foundation. From a technical perspective, it’s still the same libraries you’d have seen under Support Library and Architecture Components.”

Why is Google going through all this trouble (and creating all this trouble for developers)?

• Create a consistent namespace ( androidx.*) for the support libraries
• Support better semantic versioning for the artifacts (starting with 1.0.0). This enables them to be updated independently.
• Create a common umbrella to develop all support components under.

It is important to mention — this current version of AppCompat(v28.x) is the final release. The next versions of this code will use Jetpack exclusively. It is imperative that developers are aware, and make the switch early.

This quote from Alan Viverette sums this up nicely:

“There won’t be a 29.0.0, so Android Q APIs will only be in AndroidX”

What is in Jetpack?

The answer: everything.

Jetpack is a collection of many of the existing libraries we have been using forever (like AppCompat, Permissions, Notifications or Transitions) and the newer Architecture Components that were introduced in recent years (like LiveData, Room, WorkManager or ViewModel).

Developers can expect the same benefits they got from AppCompat, including backward compatibility and release cycles that aren’t dependent on manufacturer OS updates.

Do you have to upgrade now? Can you update only parts of your code?

You don’t have to update today, but you will have to update sometime in the near future.

The current version of AppCompat (v28.x) is exactly the same as AndroidX (v1.x). In fact, the AppCompat libraries are machine generated by changing maven coordinates and package names of the AndroidX codebase.

For example, the old coordinate and packages were:

It is important to note, you cannot mix AppCompat and Jetpack in the same project. You must convert everything to use Jetpack if you want to upgrade.

First Step — Upgrade your app to latest Support libs

When you are ready to update to Jetpack, make sure your app is upgraded to the latest versions of Gradle and AppCompat. This will ensure the refactor is only changing package names, and are not bigger issues related to library updates.

Updating your project is super important, and will expose any issues you will have with moving forward, such as a lingering dependency on an older version of a library. If you aren’t able to update to the latest versions, you will need to fix those issues before proceeding.

Don’t forget to check: https://maven.google.com for the latest Gradle dependency info.

Use the Refactor tool to update your Project

Once you have upgraded your project, you will use an Android Studio (AS) utility to do the refactor.

Run it from the menu: Refactor\Refactor to AndroidX:

This tool will scan your app, and show you a preview of the changes necessary:

If you are happy with the changes, select the “Do Refactor” button, and the conversion tool will do the following 3 things:

• Update your imports to reflect the new package names:

In general, the changes should be isolated to just these 3 areas, but in my experience, I have seen the refactor tool also make other changes. In my case, the tool added code to account for Kotlin Nullability (it added a few !! in my source code), but there likely will be other changes. It is a really good idea to closely monitor all the changes the tool makes, and ensure you are comfortable with them.

Jetifier

The AS refactor tool only makes changes to the source code in your project. It doesn’t make any changes to libraries or external dependencies.

For this, Google has created a tool named Jetifier that is designed to automatically convert transitive dependencies to use AndroidX libraries at build time. If we didn’t have this tool, we would need to wait for every 3rd party lib to update, before we could use it (and delay our update until this was ready).

Other than enabling this tool using the gradle flag, there isn’t much to know about using it, since this is an automated process, and no configuration is required.

Google recently announced a stand-alone option for running Jetifier. You can even run a “reverse mode” which will “de-jetify” code (which will be very useful for debugging).

Problems you may encounter

You may discover a 3rd party library that needs to be updated. For example, someone discovered the current version of SqlDelight required an old version of the Room persistence library. They requested an update, and Square has already provided the updated version of the lib. If you discover an issue, the sooner you can request an update from the developer the better. The newest version of Room (v2.1) already requires AndroidX, which likely will cause many folks to upgrade. As of this writing, the Facebook SDK is not updated, and this likely will be a blocker for many people.

Updating your project to the latest versions of AppCompat may not be trivial. You may have workarounds in your code for previous bugs or encounter upgrades that require significant re-work. Plan ahead to account for this work.

Source files are not modified by Jetifier, so this may be confusing when using documentation.

You can’t Jetify by Module, so this is an “all or nothing” operation on your codebase. This may require blocking ongoing development until this is resolved — otherwise you probably will encounter huge merge nightmares.

The mapping tool may insert alpha dependencies into your code (for example ConstraintLayout alpha is added).

Android Studio may not know about the Jetifier and display errors (red squigglies). Doing an Invalidate Cache and Restart should fix this.

Jetifier doesn’t modify generated code, which may require additional rework.

Some of the replacement names are not correctly mapped (these seem to be primarily from the design lib). The refactor tool won’t work for these cases, and your code won’t compile. To resolve these, you will need to manually resolve the imports. Hopefully, these issues will be minimized over time, as the tools mature and the bugs in the refactor tool are fixed.

Useful Hint:
The standard naming convention for Jetpack is to duplicate the package name into Maven coordinates. In Jetpack, the package will always match the groupid.

For example, if you know the package name was ` androidx.webkit` then the dependency will map to: ` androidx.webkit:webkit:VERSION`.

Summary

Plan ahead for the changes required by the migration to Jetpack, which will be required moving forward. The hardest part of the upgrade will likely be updating your project to the latest dependencies.

There are likely 3rd party libraries that haven’t been updated yet. It is important to identify these early and ask the developer to update them.

Resources

Full mapping of the old class names to the new ones, which can be useful if you have issues with the automated refactoring, or need to figure out a specific change.

Great article from Dan Lew, highlighting his experiences (and issues encountered) refactoring his project.

Introduction to Jetpack Blog Post from Android Developers.

Thanks to Elliot Mitchell for the proof-read, and inspiration!

Источник

Что такое AndroidX?

Я читаю о комнате библиотеки Android. Я вижу, что они изменили пакет android на androidx . Я не понимал, что. Может кто-нибудь объяснить, пожалуйста?

Даже это доступно с пакетом android .

• Зачем нужно было упаковывать новые библиотеки поддержки в androidx вместо android ?
• Вариант использования и влияние факторов в существующих проектах.

9 ответов

AndroidX — библиотека расширений Android

Мы внедряем новую структуру пакетов, чтобы было понятнее, какие пакеты связаны с операционной системой Android, а какие — с APK вашего приложения. В дальнейшем иерархия пакетов android. * Будет зарезервирована для пакетов Android, поставляемых с операционной системой. Другие пакеты будут выпущены в новой иерархии пакетов androidx. * Как часть библиотеки AndroidX.

Нужен AndroidX

AndroidX — это переработанная библиотека, чтобы сделать имена пакетов более понятными. Таким образом, теперь иерархия android будет использоваться только для классов Android по умолчанию, которые поставляются с операционной системой Android, а другие библиотеки / зависимости будут частью androidx (имеет больше смысла). Так что теперь все новые разработки будут обновляться в AndroidX.

Com.android.support. **: androidx.
com.android.support:appcompat-v7: androidx.appcompat: appcompat com.android.support:recyclerview-v7: androidx.recyclerview: recyclerview com.android.support:design: com.google.android.material: материал

AndroidX использует семантическую версию

Ранее support library использовал версию SDK, но AndroidX использует Semantic-version . Он собирается пересмотреть версию с 28.0.0 → 1.0.0.

Как перенести текущий проект

В Android Studio 3.2 (сентябрь 2018 г.) есть прямая возможность перенести существующий проект в AndroidX . Этот рефакторинг всех пакетов автоматически.

Перед миграцией настоятельно рекомендуется сделать резервную копию вашего проекта.

Существующий проект

• Android Studio> Меню рефакторинга> Миграция в AndroidX .
• Он проанализирует и откроет окно рефрактора внизу. Принять изменения, которые будут сделаны.

Новый проект

Поместите эти флаги в свой gradle.properties

Что такое Jetifier?

Ошибки миграции

• Если вы создаете приложение и после миграции обнаруживаете ошибки, вам нужно исправить эти незначительные ошибки. Вы не застрянете там, потому что это легко исправить.
• Сторонние библиотеки не преобразуются в каталог AndroidX, но они конвертируются во время выполнения с помощью Jetifier, так что не беспокойтесь об ошибках времени компиляции, ваше приложение будет работать отлично.

Поддержка 28.0.0 это последний релиз?

Это будет последний релиз функции под android.support упаковка , и разработчикам рекомендуется перейти на AndroidX 1.0.0

Так что иди с AndroidX, потому что Android теперь будет обновлять только пакет AndroidX.

Дальнейшее чтение

androidx заменит support library после 28.0.0 . Вы должны перенести свой проект, чтобы использовать его. androidx использует Semantic Versioning . Использование AndroidX не будет путать с версией, представленной в имени библиотеки и имени пакета. Жизнь становится проще

androidx — это новая структура пакетов, позволяющая понять, какие пакеты связаны с операционной системой Android, а какие — с APK вашего приложения. В дальнейшем иерархия пакетов android. * Будет зарезервирована для пакетов Android, поставляемых с операционной системой; другие пакеты будут выпущены в новой иерархии пакетов androidx. *.

Перепроектированная структура пакета должна поощрять меньшие и более сосредоточенные библиотеки. Подробную информацию о сопоставлении артефактов вы найдете здесь.

Существуют вспомогательные библиотеки (содержащие компонент и пакеты для обратной совместимости) с именем «v7», когда поддерживаемый минимальный поддерживаемый уровень SDK равен 14, новое наименование дает четкое представление о разделении между API-интерфейсами в комплекте с платформой и используемыми библиотеками для разработчиков приложений. на разных версиях Android. Вы можете обратиться к официальному объявлению для получения дополнительной информации.

AndroidX — это проект с открытым исходным кодом, который команда Android использует для разработки, тестирования, упаковки, версии и выпуска библиотек в Jetpack.

AndroidX — это значительное улучшение по сравнению с оригинальным Библиотека поддержки Android . Как и библиотека поддержки, AndroidX поставляется отдельно от ОС Android и обеспечивает обратную совместимость между версиями Android. AndroidX полностью заменяет библиотеку поддержки, предоставляя функции четности и новые библиотеки.

AndroidX включает в себя следующие функции:

Все пакеты в AndroidX живут в согласованном пространстве имен, начиная со строки androidx. Пакеты поддержки библиотеки были сопоставлены в соответствующие пакеты androidx. *. Для полного картирования всех старые классы и сборка артефактов для новых, см. Пакет Рефакторинг страницы.

В отличие от библиотеки поддержки, пакеты AndroidX поддерживаются и обновляются отдельно. Пакеты androidx используют строгий Semantic Versioning , начиная с версии 1.0.0. Вы можете обновить AndroidX библиотеки в вашем проекте самостоятельно.

Все новые разработки библиотеки поддержки будут происходить в библиотеке AndroidX. Это включает в себя обслуживание оригинальной библиотеки поддержки Артефакты и внедрение новых компонентов Jetpack.

Использование AndroidX

См. Миграция в AndroidX , чтобы узнать, как перенести существующий проект .

Если вы хотите использовать AndroidX в новом проекте, вам нужно установить SDK для компиляции на Android 9.0 (уровень API 28) или выше и установить для обоих из следующих флагов плагина Android Gradle значение true в вашем gradle.properties файле.

android.useAndroidX : при значении true плагин Android использует соответствующую библиотеку AndroidX вместо библиотеки поддержки. Флаг по умолчанию имеет значение false, если он не указан.

android.enableJetifier : при значении true плагин Android автоматически переносит существующие сторонние библиотеки в AndroidX, переписывая их двоичные файлы. Флаг является ложным по умолчанию, если это не указано.

Всего несколько слов с моей стороны ко всем доступным ответам

1. Как сказано в удивительном ответе @KhemRaj,

В соответствии с действующим соглашением об именах неясно, какие пакеты связаны с операционной системой Android , а какие — с APK вашего приложения ( Пакет Android ). Чтобы устранить эту путаницу, все разделенные библиотеки будут перемещены в пространство имен AndroidX androidx. *, А иерархия пакетов android. * Будет зарезервирована для пакетов, поставляемых с операционной системой Android.

Первоначально имя каждого пакета указывало минимальный уровень API, поддерживаемый этим пакетом, например support-v4 . Однако версия 26.0.0 библиотеки поддержки увеличила минимальный API до 14 , поэтому сегодня многие имена пакетов не имеют ничего общего с минимальным поддерживаемым уровнем API. Когда оба пакета support-v4 и support-v7 имеют минимальный API-интерфейс 14, легко понять, почему люди путаются !. Так что теперь с AndroidX нет зависимости от уровня API.

Другим важным изменением является то, что артефакты AndroidX будут обновляться независимо, поэтому вы сможете обновлять отдельные библиотеки AndroidX в своем проекте, вместо того, чтобы менять каждую зависимость сразу. Эти разочаровывающие сообщения « Все библиотеки com.android.support должны использовать точно такую же версию спецификации » должны уйти в прошлое!

AndroidX — это проект с открытым исходным кодом, который команда Android использует для разработки, тестирования, упаковки, версии и выпуска библиотек в Jetpack.

После нескольких часов борьбы я решил эту проблему, добавив в app / build.gradle следующее:

Поместите эти флаги в свой gradle.properties

При миграции на Android Studio файл приложения / Gradle автоматически обновляется с помощью реализаций библиотеки исправлений из стандартной библиотеки.

Android предоставляет несколько разных наборов библиотек. Один из них называется «Библиотека поддержки Android», а другой — «AndroidX». Выбор «Использовать артефакты Android. *» Означает, что мы хотим использовать AndroidX.

Сегодня многие считают, что библиотека поддержки является неотъемлемой частью разработки приложений для Android, так что ее используют 99 процентов приложений в магазине Google Play. Однако по мере роста библиотеки поддержки возникли несоответствия в соглашении об именах библиотеки.

Первоначально имя каждого пакета указывало минимальный уровень API, поддерживаемый этим пакетом, например, support-v4. Однако версия 26.0.0 библиотеки поддержки увеличила минимальный API до 14, поэтому сегодня многие из имен пакетов не имеют ничего общего с минимальным поддерживаемым уровнем API. Когда support-v4 и пакеты support-v7 имеют минимальный API-интерфейс 14, легко понять, почему люди путаются!

Чтобы устранить эту путаницу, Google в настоящее время реорганизует Библиотеку поддержки в новую структуру пакета Библиотека расширений Android (AndroidX). AndroidX будет содержать упрощенные имена пакетов, а также Maven groupIds и artifactIds, которые лучше отражают содержимое каждого пакета и поддерживаемые уровни API.

В соответствии с действующим соглашением об именах также неясно, какие пакеты связаны с операционной системой Android, а какие — с пакетом APK (комплект пакетов Android) вашего приложения. Чтобы устранить эту путаницу, все разделенные библиотеки будут перемещены в пространство имен AndroidX androidx. *, А иерархия пакетов android. * Будет зарезервирована для пакетов, поставляемых с операционной системой Android .

Это то же самое, что и версии поддержки AppCompat, но в нем меньше путаницы версий v4 и v7, поэтому очень полезно использовать различные компоненты XML-элементов android.

Источник