**
compileSdkVersion，targetSdkVersion和minSdkVersion
**
*compileSdkVersion
*Defines which Android SDK version is selected for application compilation. Usually, the compileSDKVersion attribute value is set to the latest API version, for example: 25. Changing the compileSDKVersion attribute value will not affect the running behavior of the Android system. For example, setting the attribute value to 25, the targetSdkVersion attribute value is 23, the code is as follows:
compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
applicationId "cn.teachcourse.demos"
minSdkVersion 11
targetSdkVersion 23
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
The developed application runs on the Android 7.0 system and will not run with the new behaviors of Android 7.0. The targetSDKVersion still determines the behavior of the Android system, so what is the use of compileSDKVersion? Select the latest API version, check code errors and warnings during compilation, and prompt developers to modify and optimize, because usually a third-party support library is introduced in an Android project, and the support library uses version 23.1.1, the attribute of compileSdkVersion The value is at least 23.0.0, and the release of the new version of the support library follows the corresponding Android system platform, which can be better compatible.
minSdkVersion
defines the minimum API version supported by the application, the minimum version is set to API 11, and the target version is set to API 24, then when the application calls methods provided by API 14, Android Studio or Eclipse development tools will remind developers to refer to an undefined method, using this method needs to set minSdkVersion to API 14 or above, as shown in the figure below:
Continuing with the above code, the result is that systems greater than or equal to Android 4.0 can execute normally, and systems less than Android 4.0 will crash when they try to access unavailable APIs at runtime.
targetSdkVersion
is the target software development version. When creating each Android project, you need to select targetSdkVersion and minSdkVersion. An attribute value of targetSdkVersion indicates which API version is used for the created Android project. An API version is represented by an integer number, and the full name of the API It is the Application Programming Interface, that is, the application programming interface. There is a difference between the programming interface corresponding to API 19 and the programming interface defined by API 23, because the attribute value of targetSdkVersion is represented by an integer number, which is easy to remember and compare the size between them. The version API programming interface can be compatible with the lower version API programming interface, and vice versa.
It is necessary to distinguish the relationship between Android 7.0 and API 24. Android 7.0 defines the version of the mobile phone system. The application program interface of this system version is defined as API 24. If the developer wants to use Android 7.0 in the developed APP The functions provided by the system include: multi-window support, notification display changes, JIT/AOT compilation, fast application installation path, etc., so novices need to choose API 24 application programming interface when creating an Android project.
In this way, we can know that the size relationship of the version number is: compileSdkVersion>targetSdkVersion>minSdkVersion
compileSdkVersion means that when compiling, the API specification will be used for code checking and warnings, but it will not be compiled into the apk.
targetSdkVersion represents the target version, and the version of the api will be compiled into the apk during compilation.
minSdkVersion represents the minimum version, which is compatible to the minimum version api specified by this parameter during compilation.
In fact, the compatibility in Android is that each api interface is compatible by judging the version of the system. For example, the most common view creation process is to judge the version of the currently running Android system before creating it, and then call the corresponding api interface. create. The version problem of targetSdkVersion and minSdkVersion is solved. It means that when packaging, the API between the highest version of the API interface and the lowest version is packaged into the apk. If it is installed in an Android system outside the scope, then the running program must not be found. Method error occurred. And if the targetSdkVersion version is lower than 23, but is installed in a system above 6.0, then the api for dynamic permission application is not packaged into the apk, so naturally the permission process of the lower version is still required, and permission can be obtained without dynamic application. As for why the Android system is compatible with the targetSdkVersion version lower than its own system, it is also because the source code has made a version judgment on the api interface call for backward compatibility.
The targetSDKVersion
simply means the system version that your app can adapt to, which means that your app has been fully processed and tested for forward compatibility on this version of the phone. In fact, we often do such a thing when writing code, that is, if(Build.VERSION.SDK_INT >= 23) { … } This is the most typical example of compatibility processing. If your target is set higher, in fact, when you call the API provided by the system, the processing you get is different, and even some new APIs are only available in the new system.
Android 6.0 normal permission and dangerous permission
Normal Permission: write in the xml file, then the app will get these permissions by default when the app is installed, even on the Android 6.0 system mobile phone, the user cannot dynamically Cancel these normal permissions, which is the same as the previous permission system, unchanged.
Dangerous Permission: It still has to be written in the xml file, but when the app is installed, the authorization will be divided into the following situations:
1. targetSDKVersion < 23 & API (Mobile System) < 6.0: Permissions are obtained by default during installation, and users cannot cancel permissions after installing the App.
3. targetSDKVersion < 23 & API (mobile phone system) >= 6.0: Authorization is granted by default during installation, but the user can dynamically cancel the authorization after the installation of the App is completed (the mobile phone will pop up a reminder when canceling, telling the user that this is an application built for an old version of mobile phone , let users operate with caution).
2. targetSDKVersion >= 23 & API (mobile phone system) < 6.0: Permissions are obtained by default during installation, and users cannot cancel permissions after installing the App.
4. targetSDKVersion >= 23 & API (mobile phone system) >= 6.0: No permission will be obtained during installation, and you can apply for permission from the user at runtime. After the user authorizes, he can still cancel the authorization in the setting interface. After the user actively cancels the setting interface, a crash may occur during the running of the app.
Give another example to illustrate the relationship between the three. Now there is a class Icon, which was added to the android frame source code in api version 23. If compileSdkVersion=28, targetSdkVersion=23, minSdkVersion=16, the compilation is There will be no problem, because my targetSdkVersion version contains the Icon class. If I set it to 22, an error will be reported, saying that this class cannot be found, because this class does not exist in the android.jar package. If I set the targetSdkVersion to 23, and when the packaged apk is installed on a 5.0 mobile phone, the program crashes. The reason for this is that android. will be packaged into the apk from the outside), and will not be packaged into the apk, so that when the apk calls the Icon class, it uses the frame layer code that comes with the Android phone. Icon is introduced in api23, and the 5.0 phone naturally does not have it. It will crash naturally.