How to Select compileSdkVersion, minSdkVersion, targetSdkVersion, and compilesdkversion

How to Select compileSdkVersion, minSdkVersion, targetSdkVersion, and compilesdkversion

Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion

Author: Ian Lake, Google Android promotion engineer; Translation: Korean Kai.

After you release an application (depending on the release time), the Android system may have released a new version in less than a few months. What does this mean to your application? Is everything useless?

Don't worry. Forward compatibility is a concern of Android. When users upgrade to the new Android version, existing applications built with the previous version of the SDK should not go wrong. This is the role of compileSdkVersion, minSdkVersion, and targetSdkVersion: They respectively control which APIS can be used, what API levels are required, and the application compatibility mode.

CompileSdkVersion

CompileSdkVersion tells Gradle which Android SDK version is used to compile your application. To use any newly added API, you must use the Android SDK of the corresponding Level.

It should be emphasized that modifying compileSdkVersion does not change the runtime behavior. When you modify compileSdkVersion, new compilation warnings and compilation errors may occur, but the new compileSdkVersion will not be included in the APK: it is only used during compilation. (You should fix these warnings for some reason)

Therefore, we strongly recommend that you always use the latest SDK for compilation. Using the new compilation check on existing code can provide many benefits, avoiding the use of new abandon APIs and preparing for using new APIs.

Note: If you use the Support Library, use the latest SDK to compile the Support Library. For example, to use the Support Library of version 23.1.1, compileSdkVersion must be at least 23 (major version numbers must be consistent !). Generally, the Support Library of the new version is released with the new system version, which provides compatibility Support for the new APIs and features of the system.

MinSdkVersion

If compileSdkVersion is set to the latest available API, minSdkVersion is the minimum requirement for applications to run. MinSdkVersion is one of the symbols used by the Google Play store to determine whether a user's device can install an application.

MinSdkVersion also plays an important role during development: lint runs in the project by default. It will warn you when you use an API higher than minSdkVersion, this helps you avoid running problems when calling non-existing APIs. If you only use some APIs on a later version of the system, you can check the system version at runtime.

Remember that your Library, such as Support Library or Google Play services, may have their own minSdkVersion. The minSdkVersion set by your application must be greater than or equal to the minSdkVersion of these databases. For example, if there are three databases whose minsdkversions are 4, 7, and 9, your minSdkVersion must be at least 9 to use them. In a few cases, you still want to use a library higher than the minSdkVersion of your application (to handle all edge situations, make sure it is only used on newer platforms ), you can use the tools: overrideLibrary tag, but perform a thorough test!

When you decide what minSdkVersion to use, you should refer to the current Android distribution statistics, which shows information about all devices accessing Google Play in the last seven days. They are potential users when you publish an application to Google Play. Ultimately, this is a business decision-making problem, depending on whether the development and testing costs are worthwhile to support an additional 3% of devices and ensure the best experience.

Of course, if a new API is the key to your entire application, it is easier to determine the value of minSdkVersion. But remember that 1.4 billion of the 0.7% devices is also a small number.

TargetSdkVersion

The three most interesting versions are targetSdkVersion. TargetSdkVersion is the primary basis for Android to provide forward compatibility. The system will not apply the latest behavior changes until the targetSdkVersion of the application is not updated. This allows you to use the new API before adapting to new behavior changes (because you have updated compileSdkVersion, isn't it ?).

Many of the behavior changes implied by targetSdkVersion are recorded in the VERSION_CODES document, but all the horrible details are listed in the highlights of each released platform, you can easily find the corresponding link in this API Level table.

For example, the Android 6.0 change document describes how to convert your application to the runtime permission model when target is set to API 23, android 4.4 behavior changes describe the behavior changes when set () and setRepeating () are used to set alarm when target is API 19 or later.

Some behavior changes are very obvious to users (the menu button is discarded, the runtime permission, and so on ), therefore, updating the target to the latest SDK is a priority for all applications. However, this does not mean that you must use all newly introduced functions, nor that you can blindly update targetSdkVersion without testing. Please do the test before updating targetSdkVersion! Your users will thank you.

Gradle and SDK versions

Therefore, it is important to set the correct compileSdkVersion, minSdkVersion, and targetSdkVersion. As you think, Gradle and Android Studio integrate them in the build system. In the build. gradle file of your module (you can also set it in the project structure option of Android Studio:

android {  compileSdkVersion 23  buildToolsVersion "23.0.1"  defaultConfig {    applicationId "com.example.checkyourtargetsdk"    minSdkVersion 7    targetSdkVersion 23    versionCode 1    versionName “1.0”  }}

CompileSdkVersion used during compilation is one of the Android settings set together with the build tool version. The other two are slightly different. They are declared at build variant. DefaultConfig is the basis for all build variants and the place where these default values are set. You can imagine that some versions of an application may have different minsdkversions in a more complex system.

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 will see a tag similar to the following:

<uses-sdk android:targetSdkVersion="23" android:minSdkVersion="7" />　　

If you manually set it in the manifest file, you will find that Gradle ignores them during build (although other build systems may depend on them explicitly ).

Overall

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

minSdkVersion <= targetSdkVersion <= compileSdkVersion

This intuition is reasonable. If compileSdkVersion is your maximum value and minSdkVersion is the minimum value, the maximum value must be at least as large as the minimum value and the target must be between them.

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

minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)

Use a lower minSdkVersion to cover the largest audience, and use the latest SDK to set the target and compile to get the best appearance and behavior. # BuildBetterApps

For details about this article, you can participate in our discussions on Google + and follow our Android Development Patterns information stream for more information.

Note: For Android Development Patterns videos, see YouTube or Youku.

Source: http://chinagdg.org/