11

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

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

... 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?

Community
  • 1
  • 1
weston
  • 54,145
  • 21
  • 145
  • 203

1 Answers1

15

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.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Interesting example of compile > target. So would you say the advice in the android docs is probably just outdated? And if you were to discover that one of your apps *could* compile with a lower sdk, would you reduce the compileSdk? – weston Aug 30 '15 at 14:09
  • @weston: "So would you say the advice in the android docs is probably just outdated?" -- possibly. I would phrase it more as "reasonable people can disagree". "And if you were to discover that one of your apps could compile with a lower sdk, would you reduce the compileSdk?" -- no. Why bother? All that does is create more work for when you decide later on to embrace something newer, for no obvious gain (at least, to me). – CommonsWare Aug 30 '15 at 14:16
  • My approach has been always compile against the latest I care about which is my target. For that reason, new features are there and ready for me to use. Like you say, relying on lint to tell me about features above min. This was my logic but your first paragraph throws doubt on this when you say you expect few to be configured like this. Why? – weston Aug 30 '15 at 14:25
  • @weston: Your approach was great before we got into code reuse. The `compileSdkVersion` will need to reflect requirements from libraries, such as the Android Support libraries, as per my example. Also, you are but one developer, and I do not expect that many developers change `compileSdkVersion` and `targetSdkVersion` in lockstep. There is nothing intrinsically wrong in doing so (modulo library requirements), but just because *you* do something does not mean that *everybody* does something. I expect that more developers treat them as largely independent variables. – CommonsWare Aug 30 '15 at 14:38
  • Well I didn't say everybody does what I do! However I did post two (of many more) examples of people on SO recommending the same. So it's a fair assumption that that advice gets followed. Counter examples exist but are less common. This makes your answer and example really useful. – weston Aug 30 '15 at 14:57
  • @weston: "So it's a fair assumption that that advice gets followed" -- some people will see the advice and follow it indefinitely. Some people will see the advice, follow it once, forget about it, and treat the values as independent down the road. Personally, I think there are more of the second group, let alone all the people who either don't run across that advice or run into enough countervailing opinions that they don't follow that advice anyway. That being said, I apologize for my tone in my previous comment. – CommonsWare Aug 30 '15 at 15:00
  • I do see your point on that and don't worry about it Mark! Thanks a lot. – weston Aug 30 '15 at 15:10
  • @CommonsWare: Maybe you have some thoughts about my initial question which startet this one: http://stackoverflow.com/questions/32295029/does-the-compile-sdk-affect-values-returned-by-android-functions - Might the compileSDK influence the return type of a function or can this never ever happen? – and_dev Aug 31 '15 at 05:27