Android Learning notes----How to choose Compilesdkversion, minsdkversion and targetsdkversion differences

This article is from the following two articles of the finishing summary
http://chinagdg.org/2016/01/picking-your-compilesdkversion-minsdkversion-targetsdkversion/
http://www.race604.com/android-targetsdkversion/

Here is a simple introduction, the following detailed instructions
Minsdkversion: Minimum requirements that the application can run
Compilesdkversion: Control which version of the API can be used
Targetsdkversion: Applied compatibility mode minsdkversion

In the name of the app, the minimum SDK version required to run is available. Phones below minsdkversion will not be installed.

Minsdkversion also plays an important role at development time: Lint is run in a project by default, and warns you when you use a higher-than-minsdkversion API to help you avoid run-time problems of invoking APIs that do not exist (for example, minsdkversion 9 but you APIs that use Sdkversion 10 will be warned.

If some APIs are used only on higher versions of the system, they are usually resolved using runtime to check the system version.
Like this.

if (Build.VERSION.SDK_INT >= build.version_codes. Lollipop) {
            //do something
}

if (Build.VERSION.SDK_INT >= build.version_codes. KitKat && Build.VERSION.SDK_INT < Build.version_codes. Lollipop) {
            //do something
}

1 2 3 4 5 6 7

compilesdkversion

Compilesdkversion tells Gradle which Android SDK version to use to compile your application. Use any newly added API to use the corresponding version of the Android SDK.

Modifying the compilesdkversion does not change the behavior at run time. When you modify the compilesdkversion, there may be a new compilation warning, compilation error, but the new compilesdkversion will not be included in the APK: it is simply used at compile time.

Note that if you use the Support library, using the latest published Support library requires the latest SDK compilation. For example, to use the 23.1.1 version of the Support Library, compilesdkversion must be at least 23.

targetsdkversion

The hardest part of three attributes is this. targetsdkversion is the main basis for Android to provide forward compatibility , and the system will not apply the latest behavioral changes until the application targetsdkversion is not updated.

The point is that as the Android system upgrades, the behavior of the API or module of a system may change, but to ensure that old APK behavior is compatible with the previous. As long as the targetsdkversion of the APK is unchanged, even if the APK is installed on the new Android system, its behavior is to maintain the behavior of the old system, thus ensuring the system's forward compatibility to the old application.

Give me a chestnut.
After the Android 4.4 (API 19), the behavior of the Alarmmanager set () and Setrepeat () was changed in the two APIs. Before Android 4.4, the two APIs were set in precise time, and the system was able to wake up Alarm at the API set point in time. Because of the power-saving reason Android 4.4 has set the wake-up time for these two APIs, the system is treated as an inexact time, and the system can only ensure that it wakes up at some point after the time you set up.

At this point, although the API does not change anything, the behavior of the API actually changes, if the API is used in the old APK, and the behavior in the application is very dependent on Alarmmanager to wake up at precise times, such as alarm clock application. If the Android system is not guaranteed to be compatible, the old APK is installed on the new system and there is a problem.

How does the Android system guarantee this compatibility? That's when the targetsdkversion work. APK in the call to the system Alarmmanager set () or Setrepeat (), the system will first check the APK targetsdkversion information, if less than 19, or according to the old behavior, that is, the exact setting of the wake-up time, no person to execute the new Behavior.

Let's take a look at some of the source code on the Android 4.4 Alarmmanger:

Private Final Boolean malwaysexact;  
Alarmmanager (Ialarmmanager service, Context ctx) {  
    mservice = service;

    Final int sdkversion = Ctx.getapplicationinfo (). targetsdkversion;
    Malwaysexact = (Sdkversion < Build.version_codes. KitKat);
}

1 2 3 4 5 6 7

See here, the first choice to get the application of the targetsdkversion, judge whether is less than build.version_codes. KitKat (API level 19) to set the malwaysexact variable to indicate whether the exact time pattern is used.

public static final Long window_exact = 0;  
public static final Long window_heuristic =-1;

Private Long Legacyexactlength () {return  
    (malwaysexact?) window_exact:window_heuristic);
}

public void Set (int type, long triggeratmillis, pendingintent operation) {  
    Setimpl (type, Triggeratmillis, Legacyexactlength (), 0, operation, NULL);

1 2 3 4 5 6 7 8 9 10

As you can see here, the set () method directly affects Setimpl () passing in different parameters, thus affecting the execution behavior of set (). Concrete implementation in the Alarmmanagerservice.java, here is not to delve down.

See here, found that the Android targetsdkversion is nothing special, the system used it is very direct, even very "rough." Just use the API below to get targetsdkversion to determine which behavior to perform:

1

We can guess that if the Android system is upgraded and this kind of compatibility behavior changes, it typically saves both old and new logic, and uses the If-else method to determine which logic to perform. Sure enough, in the source code search, we will find a lot of similar getapplicationinfo (). targetsdkversion < buid.xxxx such code, compared to the vast number of Android source, these are relatively small. In principle, this can lead to a change in the compatibility problem is the less the better, so every time the new Android version, the Android developer site will list what changes have been made here, developers need to pay special attention to.

So when we modify the APK targetsdkversion behavior changes, we have to do a complete test.

To look at the relationship between the three attributes
Minsdkversion <= targetsdkversion <= compilesdkversion

Ideally, the relationship between the three should be more like this in a stable state:
Minsdkversion (lowest possible) <= Targetsdkversion = compilesdkversion (latest SDK) br> uses a lower minsdkversion to cover the largest population and uses the latest SDK to set target and compile to get the best results for the new version.