role

When Android Studio creates a new project, build. Gradle will have targetSdkVersion, compileSdkVerson, minSdkVersion.

MinSdkVersion:

Specify the lowest device SDK version for the app to run. For example, minSdkVersion=19 indicates that the app supports Android 4.4 (API 19) devices at least. Devices with an earlier version will not be able to use the app. As the Android system version continues to be updated, the share of the previous system version is getting lower and lower. We can adjust the minSdkVersion value later according to needs.

compileSdkVersion:

It’s about compile time. For example, our current compileSdkVersion=28 (Andorid 9.0), Android 10 has a NEW API for 5G. Our app wants to use the 5G-related API as soon as possible. All you need to do is set compileSdkVersion=29 (Android 10) at compile time. It is also important to note that since this 5G API is new, you need to judge the current system version >=29 to use the new API.

targetSdkVersion

The target version is compatible with older apis. Let’s see where this field is used. For example, Android 8.0/8.1 specifies that transparent activities cannot be directed in a fixed way, otherwise an exception will be thrown. Regardless of the purpose of Google’s design for the moment, let’s imagine that our app uses transparent activity, fixed orientation, and works fine under Android 8.0. What would happen if we ran Android 8.0/8.1? Unfortunately, crash. For us, of course, this result is unacceptable, I have a good app, you upgrade the Android system directly let my app fail, there is no room for change, it is not scientific. So Google came up with a way to differentiate the behavior of the same API on different systems using the targerVersion field. Android 8.0 Activity onCreate

As can be seen from the above picture: GetApplicationInfo ().targetsdkVersion = “build.gradle”; If true, the subsequent logic (transparent and fixed direction) is executed and the exception is thrown. To disable this logic, we set targetSdkVersion below 26 (Android 8.0 for 26), even if our app runs on devices above Android 8.0, we will not have a problem. In this way, our app is not updated, but the Activity onCreate method in the new Android SDK changes part of the logical behavior. By limiting targetSdkVersion, our app can still run on the new device with the old logic, which is compatible with the old VERSION OF the API. To sum up:

For the same API(method), the new version of the system changes its internal implementation logic. The new logic may affect the App that called the API before. In order to be compatible with this problem, targetSdkVersion is introduced. When targetSdkVersion>=xx(a system version), the new logic will take effect, otherwise the old logic will be used. In other words: If you change the targetSdkVersion value, you have tested for compatibility issues.

Google recommends:

    /**
     * The minimum SDK version this application targets.  It may run on earlier
     * versions, but it knows how to work with any new behavior added at this
     * version.  Will be {@link android.os.Build.VERSION_CODES#CUR_DEVELOPMENT}
     * if this is a development build and the app is targeting that.  You should
     * compare that this number is >= the SDK version number at which your
     * behavior was introduced.
     */
    public int targetSdkVersion;
Copy the code

The general idea is: When we update targetSdkVersion, such as from 26 (Android 8.0) to 29 (Android 9.0), that means we have fully tested system compatibility between 26 and 29, so whenever we change targerSdkVersion, Fully test its system compatibility. You might say, well, I don’t have to update the targetSdkVersion value once and for all. However, if you want to use the API’s new behavior on a new system, you need to update targetSdkVersion. In addition, Google has some strong associations with targetSdkVersion, such as requiring targetSdkVersion>=26 for app uploads to Google Play (specific values vary over time).

The three links

compileSdkVersion>=targetSdkVersion>minSdkVersion