Android technology iterates and updates very quickly, and various new technologies and terms are emerging one after another. I don’t know since when, I always hear the term AndroidX from time to time. Is this another new technology? I believe that many friends will also have such doubts, so today I will write a popular science article to introduce to you the past and present of AndroidX.
When the Android system first came out, perhaps even its designers did not expect it to be so successful, so it was impossible to consider its API very thoroughly from the beginning. As the Android system version continues to be iteratively updated, many new APIs will be added to each version, but the new APIs do not exist in the old version of the system, so this creates a backward compatibility problem.
For example, when the Android system was released to version 3.0, it suddenly realized the importance of tablets. Therefore, in order to make Android more compatible with tablets, the Android team added the Fragment function to the 3.0 system (API 11). But the role of Fragment is not limited to tablets. What should I do if I also want to use this function in the old system? So the Android team launched a famous Android Support Library to provide backward compatibility functions. For example, the support-v4 library and appcompat-v7 library that everyone is familiar with belong to the Android Support Library. I believe anyone who has done Android development has used these two libraries.
But many people may not have considered what the name of the support-v4 library means. Here is an explanation. 4 here refers to the Android API version number, and the corresponding system version is 1.6. So support-v4 means that the API provided in this library will be backward compatible to Android 1.6 system. Its corresponding package name is as follows:
Similarly, appcompat-v7 refers to the backward compatibility of the API provided in the library to API 7, which is the Android 2.1 system. Its corresponding package name is as follows:
It can be found that the package names of the libraries provided in the Android Support Library all start with android.support.* .
But as time goes by, the 1.6 and 2.1 systems have long been eliminated. Now the minimum system version 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 such old systems, but their names have been retained, although their actual functions now no longer match the reasons for their original naming.
Obviously, the Android team also realized that this naming was very inappropriate, so they re-divided the architecture of these APIs and launched AndroidX. Therefore, AndroidX is essentially an upgrade to the Android Support Library. The upgrade content mainly lies in the following two aspects.
First, the package name. Previously, the package names of the APIs in the Android Support Library were under android.support.* , while the package names of all APIs in the AndroidX library have become under androidx.* . This is a big change, which means that in the future, all APIs under the android.* package will be released with the Android operating system, while the APIs under the androidx.* package will be released with the extension library. These APIs are basically not Will depend on the specific version of the operating system.
Second, naming rules. Taking advantage of the shortcomings of previous naming rules, the naming rules of all AndroidX libraries will no longer include the version number of the specific operating system API. For example, the appcompat-v7 library becomes the appcompat library in AndroidX.
A complete dependency library format of AndroidX is as follows:
implementation 'androidx.appcompat:appcompat:1.0.2'
After understanding what AndroidX is, you should relax now, right? It is actually not a brand new thing, but an upgrade to the Android Support Library. Therefore, getting started with Android There are no changes at all.
But one thing to note is that it is not recommended to mix the libraries in AndroidX and Android Support Library together, because they may cause many incompatibility problems. The best approach is to either use all libraries in AndroidX or all libraries in the Android Support Library.
Now the official attitude of the Android team is also very clear. In the future, AndroidX will be the main focus. The Android Support Library is no longer recommended for use and will slowly cease maintenance. In addition, starting from Android Studio 3.4.2, I found that newly created projects have been forced to use the AndroidX architecture.
So what should we do about the migration of old projects? Since it involves changing the package name, if you need to manually change the package name of each file when upgrading from Android Support Library to AndroidX, it will be really difficult to change. For this reason, Android Studio provides a one-click migration function. Just right-click on your project name -> Refactor -> Migrate to AndroidX, and the window as shown below will pop up.
Click Migrate here, and Android Studio will automatically check all the places where the Android Support Library is used in your project, and change them all to the corresponding libraries in AndroidX. In addition, Android Studio will also back up your original project into a zip file, so that even if there is a problem with the migrated code, you can restore the previous code at any time.
Okay, that’s all about AndroidX. I hope it can help you solve some of your doubts.