Compilesdkversion, Minsdkversion and targetsdkversion selection (copy)

English Original: Picking your compilesdkversion, minsdkversion, and Targetsdkversion

Ian lake,google Android Promotion engineer: Kai, South Korea.

When you post an app, (depending on the specific release time) it may not be a few months before the Android system releases a new version. What does this mean for your application and everything is useless?

Don't worry, forward compatibility is something that Android is very concerned about. When users upgrade to the new version of Android, existing apps built with previous versions of the SDK should not be problematic. This is what compilesdkversion, minsdkversion , and targetsdkversion do: They control which APIs they can use, what API levels are required, and the compatibility mode of the application.

Compilesdkversion

Compilesdkversion tells Gradle which Android SDK version to use to compile your app. Using any of the newly added APIs will require the corresponding level of the Android SDK.

It should be emphasized that modifying compilesdkversion does not alter the behavior of the runtime . When you modify the compilesdkversion, there may be a new compilation warning, a compilation error, but the new compilesdkversion will not be included in the APK: it is simply used at compile time. (You really should fix these warnings, their presence must be for a reason)

Therefore, we strongly recommend that you always compile with the latest SDK . Using the new compilation check on existing code can get many benefits, avoid new deprecated APIs, and prepare for the use of new APIs.

Note that if you use the support library, you will need to use the latest SDK compilation with the latest published support Library. For example, to use the 23.1.1 version of the support Library, compilesdkversion must be at least 23 (the big version number must be the same!). ）。 Typically, the new version of the support Library is released with the latest system release, which provides compatibility for the new added APIs and features of the system.

Minsdkversion

If Compilesdkversion is set to the latest available API, then minsdkversion is the minimum requirement that the app can run . Minsdkversion is one of the logos that Google Play stores use to determine whether a user device can install an app.

Minsdkversion also plays an important role in development: Lint will run in the project by default, and it will warn you when you are using an API higher than minsdkversion, and help you avoid the runtime problem of calling an API that does not exist. If some APIs are used only on higher versions of the system, they are usually resolved using the runtime to check the system version.

Keep in mind that the libraries you use, such as the support library or Google Play services, may have their own minsdkversion. The minsdkversion of your app settings must be greater than or equal to the minsdkversion of these libraries. For example, there are three libraries, and their minsdkversion are 4, 7, and 9, so your minsdkversion must be at least 9 to use them. In a few cases, you still want to use a library that is higher than the one you applied (to handle all the edge situations and make sure it is only used on newer platforms), you can use the tools:overridelibrary tag, but do a thorough test minsdkversion!

When you decide which minsdkversion to use, you should refer to the current Android distribution statistics, which shows all device information that has been accessed on Google Play in the last 7 days. They are the potential users you have when you publish your app to Google Play. Ultimately, this is a business decision issue, depending on whether the development and testing costs of ensuring the best experience are worth the effort to support an additional 3% of devices.

Of course, if a new API is the key to your entire application, it's easier to determine the value of minsdkversion. Remember, however, that 0.7% of 1.4 billion devices is a small number.

Targetsdkversion

The most interesting of the three version numbers is targetsdkversion. Targetsdkversion is the primary basis for Android to provide forward compatibility , and the system does not apply the latest behavioral changes until the app's targetsdkversion is updated. This allows you to use the new API before adapting to new behavioral changes (because you've updated compilesdkversion, haven't you?). ）。

Many of the behavioral changes hinted at by Targetsdkversion are documented in the Version_codes documentation, but all the scary details are listed in the platform highlights of each release, which can be easily found in the API level table.

For example, the Android 6.0 change document talks about how target API 23 o'clock will convert your app to the runtime permissions model, and the Android 4.4 behavior change illustrates the use of set () and Setrepeatin when Target is API 19 and above G () Set how the alarm will behave.

Since some behavior changes are very obvious to the user (Deprecated menu buttons, runtime permissions, etc.), updating target to the latest SDK is something that all applications should prioritize . But that doesn't mean you have to use all the newly introduced features, nor does it mean that you can blindly update targetsdkversion without doing any testing, and be sure to test before updating targetsdkversion ! Your users will thank you for that.

Gradle and SDK versions

So it is important to set the correct compilesdkversion, minsdkversion and Targetsdkversion. As you can imagine, both Gradle and Android Studio integrate them in the build system. In your module's Build.gradle file (also available in the project structure options in Android Studio):

Android {compilesdkversion buildtoolsversion "23.0.1" defaultconfig {ApplicationID "Com.example.checkyourtarget SDK "Minsdkversion 7 targetsdkversion Versioncode 1 Versionname" 1.0 "}}

The compilesdkversion used at compile time is one of the Android settings set up with the build tool version. The other two are slightly different, they are declared there in the build variant (build variant). Defaultconfig is the basis for all build variants and is where these default values are set. You can imagine that in a more complex system, some versions of the app might have different minsdkversion.

Another difference between minsdkversion and Targetsdkversion and Compilesdkversion is that they will be included in the final APK file, if you view the generated Androidmanifest.xml file, You'll see a label like this:

<USES-SDK android:targetsdkversion= "android:minsdkversion=" 7 "/>

If you set it up manually in the manifest file, you will find that Gradle ignores them when they are built (although other build systems may be explicitly dependent on them).

In a comprehensive view

If you configure as shown in the example above, you will find that the relationship between the three values is:

Minsdkversion <= targetsdkversion <= compilesdkversion

This intuition is reasonable, if compilesdkversion is your maximum value, minsdkversion is the minimum value, then the maximum must be at least as large as the minimum value and target must be between the two.

Ideally, the three relationships should be more like this in a stable state:

Minsdkversion (lowest possible) <= Targetsdkversion = compilesdkversion (latest SDK)

Use the lower Minsdkversion to reach the largest crowd and set the target and compile with the latest SDK to get the best look and behavior. #BuildBetterApps

Compilesdkversion, Minsdkversion and targetsdkversion selection (copy)