I was about to use a constraint-layout in my project when I noticed that there are two different dependencies that I can use:
com.android.support.constraint:constraint-layout
androidx.constraintlayout:constraintlayout
Is there a difference between these two or some recommendation on which is preferable?
EDIT
Google is stopping support for com.android.support and prompts users to migrate to the new androidx equivalent.
Note: With the release of Android 9.0 (API level 28) there is a new version of the support library called AndroidX which is part of Jetpack. The AndroidX library contains the existing support library and also includes the latest Jetpack components.
You can continue to use the support library. Historical artifacts (those versioned 27 and earlier, and packaged as android.support.*) will remain available on Google Maven. However, all new library development will occur in the AndroidX library.
We recommend using the AndroidX libraries in all new projects. You should also consider migrating existing projects to AndroidX as well.
Here is the official Migration guide and the corresponding library equivalents.
All the support libraries are dropping the v4 v7 v12 v13 etc tags and everything is refactored into the androidx packages.
They are essentially the same but for future reference androidx will be the library that we should use in our apps.
Android studio 3.2 canary that comes out this week (week of May 14, 2018) should have the tool that allows automatic refactoring to the androidx packages. There was an announcement about this at google i/o 2018.
One of the difference between AndroidX and Support libraries is that when you use Support libraries, all Support libraries must be the same version, but in AndroidX there is no such thing.
Other thing is that in Support library, most of the time when you need a component in your app, you have to add dependencies that have so many other thing that you really don't need. But in AndroidX you can add only the dependency that you need and no more.
This might help,
There are a few differences as follows:
With the current naming convention, it isn’t clear which packages are bundled with the Android operating system, and which are packaged with your application’s APK (Android Package Kit). To clear up this confusion, all the unbundled libraries will be moved to AndroidX’s androidx.* namespace, while the android.* package hierarchy will be reserved for packages that ship with the Android operating system.
For example: android.content.Intent; is Android OS dependent & androidx.fragment.app.Fragment; this is shipped with APK
Initially, the name of each package indicated the minimum API level supported by that package, for example support-v4. However, version 26.0.0 of the Support Library increased the minimum API to 14, so today many of the package names have nothing to do with the minimum supported API level. When support-v4 and the support-v7 packages both have a minimum API of 14, it’s easy to see why people get confused!. So now with AndroidX, there is no dependence on the API level.
This is just an extension to the 2nd point, another important change is that the AndroidX artifacts will update independently, so you’ll be able to update individual AndroidX libraries in your project, rather than having to change every dependency at once. Those frustrating “All com.android.support libraries must use the exact same version specification” messages should become a thing of the past!
As said above and in Migrating to AndroidX, you can easily migrate in AS:
With Android Studio 3.2 and higher, you can quickly migrate an
existing project to use AndroidX by selecting Refactor > Migrate to
AndroidX from the menu bar.
Concerning the difference (TLDR: no impairments, emphasis mine)
AndroidX maps the original support library API packages into the
androidx namespace. Only the package and Maven artifact names changed;
class, method, and field names did not change.
Related
In my mind, androidx.* is optional for an Android project, I find that androidx.* is necessary when I update to Android Studio to 3.4.2.
See the Image. So androidx.* will be standard, right?
Image
AndroidX is a major improvement to the original Android Support Library.
Like the Support Library, AndroidX ships separately from the Android OS and provides backwards-compatibility across Android releases. androidX fully replaces the Support Library by providing feature parity and new libraries.
Here
If your app currently depends on the original Design Support Library, you can make use of the Refactor to androidX option provided by Android Studio. Doing so will update your app’s dependencies and code to use the newly packaged androidx.
New Design support library requires andriodX migration too! You should consider using androidX for your future projects! Here
Add the library to the in your build.gradle(app-level) dependencies section:
implementation 'com.google.android.material:material:version' Latest Version
you can still make app absolutely..androidx is just a extension of the android library itself...so if you completely know android libraries,you can make any app,same as what androidx can,as the name implies,its a "support library" so without using it you can still make full blown app...again its a support library to make your life not worrying of compatibility for your app,but if your really know android programming,your dont need androidx.infact making app in android(not androidx)is better because you dont need transitions in the future same to what happen to those who rely on android support libraries..
I have Android App that uses support library versions 27.1.2. I want to consume a library written using Android X (api 28).
There are few issues with name spacing of the library versions.
Example ...
The library has a Dialog that I want to use with the api
Dialog.show(androidx.fragment.app.FragmentActivity activity);
However all my activities are using
android.support.v4.app.FragmentActivity
and the compiler does not like this.
Currently it is not an option to upgrade my project to latest version, so please no upgrade answers, unless this is the only solution.
Is there a way to resolve this incompatibility issue?
Thanks in advance.
This is not possible. To use any library that depends on AndroidX, your project must migrate your whole project to AndroidX.
Note that the reverse is supported - you can use libraries built with Support Library in projects that use AndroidX (that's the purpose of the android.enableJetifier=true flag).
AndroidX[About]
Consumer support -> Producer androidX - not compatible.
You should migrate your consumer to use AndroidX. Android Studio menu -> Refactor -> Migrate to AndroidX...
Consumer androidX -> Producer support - compatible.
Consumer's gradle.properties in addition to use androidX should enable Jetifier[About] which converts support to androidX
android.useAndroidX=true
android.enableJetifier=true
[Mix AndroidX and support in a multi-module project]
There is a way
Jetifier tool migrates support-library-dependent libraries to rely on the equivalent AndroidX packages instead. But when you put -r flag, it makes him to the exactly reverse process.
From developer.android.com
If you pass the -r flag, the utility runs in reverse mode. In this
mode, the utility converts AndroidX APIs to the support library
equivalents, instead of the other way around. Reverse mode is useful,
for example, if you are developing libraries that use AndroidX APIs,
but also need to distribute versions that use the support library.
Anyway, I will suggest to use it only in a very critical needs.
I have written a library that supports AndroidX.
How can I use this library with migration if I don't want to migrate my project to AndroidX yet?
Many popular libraries that have supported AndroidX say something like "If you wish to use this library now, migrate to AndroidX or use old versions". So I don't think you can use an AndroidX library with an non-AndroidX project.
Support libraries and AndroidX have different package name space. In the future, new changes in the AndroidX libraries won't be available in the support libraries.
Migrate the project to AndroidX or downgrade the library to support library.
Update
As mlyko's comment mentioned, jetifier has a reverse mode:
https://developer.android.com/studio/command-line/jetifier#reverse_mode
In this mode, the utility converts AndroidX APIs to the support library equivalents, instead of the other way around. Reverse mode is useful, for example, if you are developing libraries that use AndroidX APIs, but also need to distribute versions that use the support library.
I haven't tried it but it seems promising.
You could try the jetifier-standalone in reverse mode, to provide build with support libraries. Therefore you'd have 2 releases of the library - androidx and support lib.
Google launch an early preview of the new Android extension libraries (AndroidX) which is basically new replacement of existing android support library and architecture packages as per their documentation.
But what is the actual difference between theseandroid and androidx package. Proper use case of these two packages and how can we convert existing android packages to androidx package. Which packages/libraries support these conversion?
AndroidX is basically a big refactoring Google's made on their package structure. They changed the location of many classes to make it clearer which classes are bundled with the system and which ones aren't.
As stated on their docs:
We are rolling out a new package structure to make it clearer which
packages are bundled with the Android operating system, and which are
packaged with your app's APK. Going forward, the android.* package
hierarchy will be reserved for Android packages that ship with the
operating system; other packages will be issued in the new androidx.*
package hierarchy.
The old support libs up to version 28 will remain available as they are, but the new versions of the support lib will be released under the AndroidX package refactor, starting from version 1.0.0.
Also, as taken from their refactoring list:
Only the package and Maven artifact names are affected; class, method,
and field names are not changing.
In other words, they're just organizing their libs. You can read more about that on their blog post.
AndroidX is the open-source project that the Android team uses to develop, test, package, version and release libraries within Jetpack.
AndroidX is a major improvement to the original Android Support Library. Like the Support Library, AndroidX ships separately from the Android OS and provides backwards-compatibility across Android releases. AndroidX fully replaces the Support Library by providing feature parity and new libraries. In addition AndroidX includes the following features:
All packages in AndroidX live in a consistent namespace starting with the string androidx. The Support Library packages have been mapped into corresponding androidx.* packages. For a full mapping of all the old classes and build artifacts to the new ones, see the Package Refactoring page.
Unlike the Support Library, AndroidX packages are separately maintained and updated. The androidxpackages use strict Semantic Versioning starting with version 1.0.0. You can update AndroidX libraries in your project independently.
All new Support Library development will occur in the AndroidX library. This includes maintenance of the original Support Library artifacts and introduction of new Jetpack components.
Source : AndroidX Overview
This question already has an answer here:
How do make sure there is no conflict of "v7 appcompat or support" of my library when any application uses my library?
(1 answer)
Closed 6 years ago.
I have a android library with com.android.support:appcompat-v7:23.0.1 dependency in the gradle with compliedSDK of 23
I have following doubts
case 1) Say any applicaion with different version com.android.support:appcompat-v7:23.3.0 uses my library.
which version does the android take? Lower one or Higher one? How do i see it?
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
case 2) Say any applicaion with different version com.android.support:appcompat-v7:25.0.1 or com.android.support:appcompat-v7:24+ and different compiledSDk(24 or 25) uses my library.
I know that The support library should not use a different version than the compileSdkVersion.
How does the android merge the support libraries now? (Since the support library version(appcompat-v7:23.0.1) of my library is different from that of the application's compiledSDK (25) )
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
Anyone Please clear my doubts
which version does the android take? Lower one or Higher one? How do i see it?
When building library you put the dependency explicitly in build.gradle. The same is done by the creator of app, that uses your library as a dependency declared in his build.gradle. If the creator explicitly declares support library as a dependency, that version is taken (regardless the versions declared by dependencies). If he does not do that, the highest version declared by any dependency is taken (such support library is regarded as a transitive dependency).
Example: Your library uses appcompat-v7:23.3.0. The creator of app declared appcompat-v7:25.0.1. Simple case: appcompat-v7:25.0.1 is taken.
Example 2: Your library uses appcompat-v7:23.3.0. The creator of app does not use appcompat-v7. appcompat-v7:23.3.0 will be in output app.
Example 3: Your library uses appcompat-v7:23.3.0. Another library uses appcompat-v7:24.1.0. If the creator does not explicitly declare appcompat-v7:xx.x.x the version appcompat-v7:24.1.0 will be in output app.
Hope you understand.
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
You can't assure that. That is why you should always put the highest version of support libraries in the library. I can't even assure you the support libraries maintain backward compatibility. Here is the example that they don't.
I know that The support library should not use a different version than the compileSdkVersion.
That is only a suggestion. However, you should conform to it, but you don't have to.