应该编译sdk低于目标sdk

Question

The overwhelming advice on SO is that compile SDK should usually match target SDK.

• https://stackoverflow.com/a/27629181/360211

Likewise it is advisable to have this [compileSdk] match you target sdk version.

• https://stackoverflow.com/a/28294447/360211

... CompileSDK (usually equal to target SDk version) version.

But the clear advice here is:

In general, you should compile your application against the lowest possible version of the platform that your application can support.

I've always made compile sdk match target sdk, but since reading that I realize that I, and many SO answers are wrong.

My question is, what's the harm in making them match or conversely what's the advantage of having the lowest compile sdk version you can get away with?

Answer 1

The overwhelming advice on SO is that compile SDK should usually match target SDK.

Really? I would expect few production Android apps to be so configured, outside of newly-created projects, where the new-project wizards tend to set up equal values for those.

what's the harm in making them match

There is no particular harm in making them match. There is no particular harm in making them not match. It all depends on what you are writing and what behavior you want.

For example, Android 6.0 introduces a new runtime permissions model, where you have to add code to your app to request dangerous permissions from the user, for everything from WRITE_EXTERNAL_STORAGE to READ_CONTACTS . However, this is only used if targetSdkVersion is 23 or higher. If you are not in position to deal with that code change right now, you would specifically leave your targetSdkVersion at something lower, like 22.

However, at the same time, perhaps you want to use the v23 editions of key Android support libraries, like appcompat-v7 . Generally speaking, you will want your compileSdkVersion to match the major version of the support libraries that you are using, as they may be referencing classes, methods, constants, and such that are only available in that compileSdkVersion .

And so, this would be a case where you specifically do not want compileSdkVersion to match targetSdkVersion .

what's the advantage of having the lowest compile sdk version you can get away with?

Nowadays, there is little to no advantage, IMHO.

Back in 2008-2011, a common (albeit flawed) recommendation was to have compileSdkVersion match minSdkVersion (or, in truth, their Eclipse/Ant equivalents, since Android Studio didn't exist back then). This was because we lacked tools to automatically tell us if we used something that was valid in our compileSdkVersion (say, 11) but was not available all the way to our minSdkVersion (say, 4). Setting those two values equal meant you got compiler errors if you tried using stuff newer than the minSdkVersion . The downside is that you were stuck with the feature set from your minSdkVersion and could not progressively enhance your app to take advantage of newer features available on newer devices.

Nowadays, the build tools (specifically Lint) will yell at you if you try using things that are valid in your compileSdkVersion but not available all the way back to the minSdkVersion , so you know to put in the appropriate Build.VERSION.SDK_INT checks to ensure you only use the newer stuff on newer devices and gracefully degrade on older devices.