最近看到了一片国外的资料，google开发工程师贡献的一片如何设置compileSdkVersion, minSdkVersion, and targetSdkVersion，讲的很官方很正解，收藏一下，结尾给出了本篇的结论，大家可以看一下，顺便练一下英文。
Dependingon the time of the year, it might only be a few months after you release an appthat a new version of Android is announced. What does that mean for your appthough — is everything going tobreak?
You’llbe happy to know that forward compatibility is a strongfocus of Android — existing apps built against prior SDKs should not break when the userupdates to a new version of Android. This is where compileSdkVersion, minSdkVersion,and targetSdkVersion come in: they control what APIs areavailable, what the required API level is, and what compatiblity modes areapplied, respectively.
compileSdkVersion
compileSdkVersion isyour way to tell Gradle what version of the Android SDK to compile your appwith. Using the new Android SDK is a requirement to use any of the new APIsadded in that level.
Itshould be emphasized that changing your compileSdkVersion does not changeruntime behavior. While new compiler warnings/errors may bepresent when changing your compileSdkVersion, your compileSdkVersion is notincluded in your APK: it is purely used at compile time. (You should really fixthose warnings though — they were added for a reason!)
Thereforeit is strongly recommended that you always compile with the latest SDK.You’ll get all the benefits of new compilation checks on existing code, avoidnewly deprecated APIs, and be ready to use new APIs.
Notethat if you use the Support Library,compiling with the latest SDK is a requirement for using the latestSupport Library releases. For example, to use the 23.1.1 Support Library, youmust have a compileSdkVersion of at least 23 (those first numbers need tomatch!). In general, a new version of the Support Library is released alongsidea new platform version, providing compatibility shims to newly added APIs aswell as new features.
minSdkVersion
IfcompileSdkVersion sets the newest APIs available to you, minSdkVersion isthe lower bound for your app. The minSdkVersion is one of thesignals the Google Play Store uses to determine which of a user’s devices anapp can be installed on.
Italso plays an important role during development: by default lint runs againstyour project, warning you when you use any APIs above your minSdkVersion,helping you avoid the runtime issue of attempting to call an API that doesn’texist. Checking the system version at runtime is a common technique when using APIs only on newer platformversions.
Keepin mind that libraries you use, such as any of the Support Libraries or Google Play services,may have their own minSdkVersion — your app’s minSdkVersion must be at least as high as your dependencies’ minSdkVersion — if you have libraries thatrequire 4, 7, and 9, your minSdkVersion must be at least 9. In rare cases whereyou want to continue to use a library with a higher minSdkVersion than your app(and deal with all edge cases/ensure the library is only used on newer platformversions), you can use the tools:overrideLibrary marker, but make sure to test thoroughly!
Whendeciding on a minSdkVersion, you should consider the stats on theDashboards,which give you a global look on all devices that visited the Google Play Storein the prior 7 days — that’syour potential audience when putting an app on Google Play. It is ultimately abusiness decision on whether supporting an additional 3% of devices is worththe development and testing time required to ensure the best experience.
Ofcourse, if a new API is key to your entire app, then that makes theminSdkVersion discussion quite a bit easier. Just remember that even 0.7% of1.4 billion devices is a lot of devices.
targetSdkVersion
Themost interesting of the three, however, is targetSdkVersion. targetSdkVersionis the main way Android provides forward compatibility bynot applying behavior changes unless the targetSdkVersion is updated. Thisallows you to use new APIs (as you did update your compileSdkVersion right?)prior to working through the behavior changes.
Muchof the behavior changes that targetSdkVersion implies are documented directlyin the VERSION_CODES,but all of the gory details are also listed on the each releases’ platformhighlights, nicely linked in the API Levels table.
Forexample, the Android 6.0 changes talkthrough how targeting API 23 transitions your app to the runtime permissions model and the Android 4.4 behavior changes detail how targeting API 19 or higher changes how alarms setwith set() and setRepeating() work.
Withsome of the behavior changes being very visible to users (the deprecation of the menu button, runtime permissions, etc), updating to target the latest SDKshould be a high priority for every app. That doesn’t meanyou have to use every new feature introduced nor should you blindly update yourtargetSdkVersion without testing — please, please test before updating your targetSdkVersion! Your users will thank you.
Gradle and SDK versions
Sosetting the correct compileSdkVersion, minSdkVersion, and targetSdkVersion isimportant. As you might imagine in a world with Gradleand Android Studio,these values are integrated into the tools system through inclusion in yourmodule’s build.gradle file (also available through the Project Structure optionin Android Studio):
android {
compileSdkVersion 23
buildToolsVersion “23.0.1”
defaultConfig {
applicationId “com.example.checkyourtargetsdk"
minSdkVersion 7
targetSdkVersion 23
versionCode 1
versionName “1.0”
}
}
ThecompileSdkVersion, being a compile time thing (who would have guessed!), is oneof the android settings alongside with your build tools version. The other twoare slightly differently in that they are declared at the build variant level — the defaultConfig isthe base for all build variants and where’d you put default values for these,but you could imagine a more complicated system where specific versions of yourapp have a different minSdkVersion for example.
minSdkVersionand targetSdkVersion also differ from compileSdkVersion in that they areincluded in your final APK — if you were to look at the generated AndroidManifest.xml,you’d see a tag such as:
<uses-sdk android:targetSdkVersion=”23" android:minSdkVersion=”7" />
You’llfind if you manually put this in your manifest, it’ll be ignored when you buildwith Gradle (although other build systems might certainly rely on it beingthere).
Putting it all together
Ifyou made it through the bolded notes, you’ll notice arelationship between the three values:
minSdkVersion <= targetSdkVersion <= compileSdkVersion
Thisintuitively makes sense — if compileSdkVersion is your ‘maximum’ and minSdkVersion is your ‘minimum’ then your maximum must be at least as high as your minimum and thetarget must be somewhere in between.
Ideally,the relationship would look more like this in the steady state:
minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)
You’llhit the biggest audience with a low minSdkVersion and look and act the best bytargeting and compiling with the latest SDK — a great way to#BuildBetterApps.