Android technology is iterating fast, with new technologies and terms popping up all over the place. AndroidX is a new technology. AndroidX is a new technology. I believe there are many friends will also have such doubts, today to write a popular science article, to introduce you to the past life of AndroidX.

When The Android system first came out, even its designers probably didn’t expect it to be so successful, so it’s unlikely that the API was well thought out from the beginning. As versions of Android are updated over time, many new apis are added in each version, but the new apis are not in the old version, so there is a problem of backward compatibility.

For example, when The Android system was released to version 3.0, the importance of tablets was suddenly realized. Therefore, in order to make Android better compatible with tablets, the Android team added the Fragment function in system 3.0 (API 11). But fragments aren’t limited to tablets. What if you wanted to use them on older systems? As a result, the Android team launched a well-known Android Support Library to provide backward compatibility. For example, the support-V4 and AppCompat-V7 libraries, which are familiar to everyone, belong to the Android Support Library and are believed to be used by anyone who has done Android development.

But many people may not have thought about what the support-V4 library name actually means, so here’s an explanation. 4 here refers to the Android API version number, which corresponds to the system version 1.6. Support-v4 means that the API provided in this library will be backward compatible with Android 1.6. Its corresponding package name is as follows:

Similarly, AppCompat-v7 refers to the backward compatibility of the apis provided in the library to API 7, or Android 2.1. Its corresponding package name is as follows:

The Android Support Library provides libraries whose package names begin with Android.support.*.

However, with the passage of time, the 1.6 and 2.1 systems have long been eliminated. Now the lowest version of the system officially supported by Android is 4.0.1, and the corresponding API version number is 15. The support-V4 and AppCompat-V7 libraries no longer support systems as old as they were, but their names have stuck, even though they don’t actually do what they were named for anymore.

It’s clear that the Android team realized that the naming wasn’t appropriate enough, so they reorganized the ARCHITECTURE of these apis and launched AndroidX. Therefore, AndroidX is essentially an update to the Android Support Library in two main ways.

First, the package name. All apis in the Android Support Library have package names under Android.support.*, while all apis in the AndroidX Library have package names under AndroidX.*. This is a big change, meaning that the apis under the Android.* package will be shipped with the Android operating system, while the apis under the AndroidX.* package will be shipped with the extension library, and these apis will be largely independent of the specific operating system version.

Second, naming rules. Taking advantage of the previous naming conventions, AndroidX library naming conventions no longer include the version number of the specific OS API. For example, libraries like appcompat-v7 become appcompat libraries on AndroidX.

A complete AndroidX dependency library format looks like this:

implementation 'androidx. Appcompat: appcompat: 1.0.2'Copy the code

Now that you know what AndroidX is, you should relax, right? It’s not really anything new, but an update to the Android Support Library. Therefore, AndroidX is not difficult to use, such as before you often use RecyclerView, ViewPager and other libraries, there will be a corresponding version in AndroidX, as long as you change the package name can be completely seamless use, usage basically no change.

It is important to note, however, that mixing libraries in AndroidX and Android Support Library is highly discouraged, as they can cause incompatibility issues. Your best bet is to either use all of the libraries in AndroidX or all of the libraries in the Android Support Library.

Now the Official attitude of the Android team is very clear, the future will be dominated by AndroidX, Android Support Library is no longer recommended, and will gradually stop maintenance. Also, starting with Android Studio 3.4.2, I noticed that new projects have been forced to use the AndroidX architecture.

So what about the migration of older projects? Because of the package name changes involved, upgrading from Android Support Library to AndroidX would be a real nightmare if you had to manually change the package name of every file. To do this, Android Studio offers a one-click migration feature. Just right click on your project name → Refactor → Migrate to AndroidX and you will see a window like the one shown below.

Click Migrate here and Android Studio will automatically check all areas of your project that use the Android Support Library and change them to the corresponding libraries in AndroidX. Android Studio also backs up your original project into a ZIP file, so you can always revert to the original code if something goes wrong with the migrated code.

The above is about AndroidX content here, I believe that is also able to solve the doubts in the hearts of many friends.