“This article has participated in the good article call order activity, click to see: back end, big front end double track submission, 20,000 yuan prize pool for you to challenge!”
In the Build. gradle configuration file of Android development project, a total of four different SDkversions can be defined. Here is a simple comparison and summary of their usage scenarios and similarities and differences.
minSdkVersion
Defines the minimum API level required to run the app
This is easy to understand. MinSdkVersion is the lowest SDK version supported by the Android project, and therefore the lowest version of the Android API available. For example, if minSdkVersion = 24, which is Android 7, then running the APP on a device with Android 6 or below will cause an error: The minimum Accepted SDK version of your app is Android 7
Another benefit of minSdkVersion is the Link check to get hints about the higher version of the Android API currently in use. For example, when minSdkVersion = 24, if you call a new function introduced by Android 11 in your code, the compiler will warn you and ask you to add an SDK version check logic before your code.
private fun setUpActionBar(a) {
/ / that can invoke in the android version 11 or more setDisplayHomeAsUpEnabled () method
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
actionBar.setDisplayHomeAsUpEnabled(true)}}Copy the code
In addition, it is important to note that if the project’s multiple dependency libraries have different minsdkversions, the APP’s minSdkVersion should be the one with the highest minSdkVersion. If your project has three dependent libraries with minimum SDK version 20, 22, and 24, then the minSdkVersion of the project itself must be 24 or higher, which is a backward compatibility problem.
maxSdkVersion
Like minSdkVersion, maxSdkVersion is the highest SDK version supported by an Android project, but the Platform itself is perfectly backward compatible, so this parameter is generally not set at all. Of course, once set, the project will report an error or fail to install when running on a device with a version number higher than maxSdkVersion.
complieSdkVersion
compileSdkVersion specifies the Android API level Gradle should use to compile your app. This means your app can use the API features included in this API level and lower.
It gets a little more complicated from here. CompileSdkVersion literally tells the compiler which Android version your Android project will compile on. Most importantly, compileSdkVersion only defines the compile time version number and has no effect on runtime behavior. So what does it affect? In fact, it mainly affects the use of the API introduced at the beginning of a version. Also for example, if an API was introduced in the Android X version, you can only use the API when compileSdkVersion is equal to or higher than X. According to the Google docs, Google strongly recommends setting compileSdkVersion to the latest version for several reasons:
- You will get all benefits of new compilation checks on existing code.
- Avoid using newly deprecated apis; avoid using newly deprecated apis
- Ready to use any new API is available.
One more point to note: If the Android Project uses the Android Support Library, complieSdkVersion must be greater than or equal to the Support Library’s major version number (the first number of the version number). For example, if your project is using Android Support library version 23.1.1, complieSdkVersion must be at least 23 and above to compile. If the project uses the AndroidX libraries, complieSdkVersion needs to be at least 28 and above to be compiled.
targetSdkVersion
The last and most interesting one is targetSdkVersion. We said above that compileSdkVersion does not affect runtime behavior whereas targetSdkVersion does the opposite. It affects runtime behavior. It literally refers to which version of Android your Android project is targeted for development.
For example, Android 6 (SDK version 23) introduced Runtime Permission Check. If your project is set to targetSdkVersion 22 or below, The system will know that your APP was written for version 22 or lower. At this point, if the project is running on an Android 6 device, the system will still enable runtime application rights management, but the system will take over and process it completely. In this way, you can ensure that a lower-version project running on a higher-version device can use the new version features without paying attention to behavioral changes.
So since the use of new features and backward compatibility are not affected, can targetSdkVersion always be kept at a very low version? In fact, Google recommends that developers keep the targetSdkVersion number up to date at all times, as too low a version number can result in rejection of the app market. Also, be sure to do a full set of tests after updating the targetSdkVersion to ensure that the behavior changes have no impact.
SdkVersion comparison
Here is a comparison and summary of the three versions except maxSdkVersion(which is too little used) :
The default value | Whether to save in the final generated APK | Position statement | |
---|---|---|---|
minSdkVersion | 1 | is | android -> defaultConfig |
compileSdkVersion | None (must be declared in build.gradle) | no | android |
targetSdkVersion | minSdkVersion | is | android -> defaultConfig |
So ideally, there should be a relationship between the project version numbers as follows:
MinSdkVersion (smaller is better) <= targetSdkVersion == compileSdkVersion(keep up to date with SDK version)
A smaller version of minSdkVersion allows your project to support more different versions of devices, while a higher version of compileSdkVersion allows you to keep track of new apis and features, making it easier to maintain your project.
conclusion
When I first came into contact with Android development, I was always confused about the four SDK version numbers in build.gradle configuration file, so I went to Google’s official documents and other blog posts to compare their similarities and differences in a more comprehensive and complete way to deepen my understanding. That’s the whole purpose of this article, and I hope it helps you.
Refer to the article
Google Android Developer Doc – SDK Versions
Google Manifest <uses-sdk> tag
Picking your compileSdkVersion, minSdkVersion, targetSdkVersion
Using androidx libraries in your project