Difference between androidx and com.android.support

Question

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.

Answer 1

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.

Answer 2

This might help,

There are a few differences as follows:

1. 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

2. 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.

3. 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!

Answer 3

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.

Answer 4

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.