Android : Consequences of having targetSDK > BuildTarget

Question

I wanted to know the consequences of having targetSDK > buildTarget.

I recently observed that if I keep the buildTarget=16 and targetSDK=17 the tabs on my tablet (running 4.1.1, API Level 16) moves to the center of the actionBar. I was unable to rationalize the behavior. Can somebody shed some light on why this happened?

Answer 1

Nice question! I had a similar behavior some time ago, when buildTarget and targetSDK differed in the described way. It took me some time, to figure it out, but I will try to summarize my understanding.

You have to distinguish between three important values:

1. minSdkVersion:

   This is the lowest available version, on which the app will (or should!) run. When installing an .apk onto Android, the value will be checked and if the Android version you're running on, is lower than the specified version, it won't install.

2. buildTarget:

   That's the SDK on which the application's .apk will be compiled (and Eclipse will be target that value too, for checking for compilation errors). If the buildTarget is higher than the minSdkVersion, you will be able to install the app even if your Android version does not support all methods. By default, this is set to the latest version of Android available in your SDK. You can still build your app to support older versions, but setting the build target to the latest version allows you to enable new features and optimize your app for a great user experience on the latest devices.

   You need to check if the methods you are using are present at runtime if running on a lower API level, otherwise the application might crash!

3. targetSdkVersion:

   The targetSdkVersion specifies on which SDK platform your app should run fine. So, if you tested against API 17, you can add API 17 as targetSdkVersion. If using an Android version > targetSdkVersion, the Android system will enter into some kind of forward-compatibility mode to ensure support for the application. This compatibility behavior will be entered to ensure that your app continues to work the way you expect, as there might be some changes in behavior between never API levels (here are some of the most important changes). So, any application developed for a lower API level will be able to run on a higher version, as the old behavior (like obsolete values) might be "simulated" within the compatibility mode.

   For example:

   If you set targetSdkVersion to HONEYCOMB (API 11), the default theme will be changed to Theme_Holo (that's the dark holographic UI). Setting targetSdkVersion to a lower value will affect the system to stay on the default light theme, regardless which build API you will use!

   In your case, there don't seem to be many noticeable changes between API 16 and 17, that should affect in a design change, but I guess, the higher targetSdkVersion will affect in some additional changes at compile time (like including additional classes, themes, values, ...), that will affect in a different behavior, just like in the theme example above.

I hope, that helped you a bit, to figure out the weird behavior. Here is some more related information to read in the Android Developer documentation.

PS: There is some kind of forward-backward-hell: The Android system is backward-compatible, so that the forward compatibility of Android applications is ensured. That means: If you update your Android version via OTA e.g., all old applications should stay running (so they will stay forward compatible).

Answer 2

The build target is for app development, the target SDK is for app compatibility.

The build target specifies which API you have access to while implementing the app. Like if you set the build taget to android API level 10 then as far as your code is concerned, there is no such thing as an ActionBar. The API you use during development is just a stub implementation of Android, this is way it has to be emulated or run on a real device. Therefore, the build target defines (to the compiler and your IDE) Android interface you are using. Once compiled, there should be no difference based on build target (the Android system doesn't see the build target, it's a compile-time flag). This is a strict contract between you and the android compiler (and your IDE) that defines which components in Android you are able to use in your application, as you will get compilation errors if you try to use something that is beyond the Android version set as your build target.

The target SDK is a contract you sign with the Android system, assuring it that your app is prepared to work properly from you minimum SDK up through to the target SDK (effective the maximum SDK, as the maximum SDK setting should generally be avoided). I believe there are a few things that don't get forward-compatibility, like some of the security changes (probably changes the come from beyond app development and are system-wide). This contract is an agreement that means you have performed measures to make sure that your app handles any changes in the Android API in that range, such that it provides behavior you expect in all situations. The other end of the contract is from the Android system, it agrees to use Android implementation that does not exceed your target SDK, even when on a device running a higher version of Android (this excludes the few changes that I mentioned previously).

The note on forward-compatibility implies that your build target should always at least match your target SDK. You are saying that you have tested your app to run at your target SDK, so why build it against a lower API level?

Real life example of build target and target SDK in action: ActionBarSherlock provides backward-compatible ActionBar. Here are quotes from requirements to use the library at this time.

The library itself must be built against Android 4.0 (API level 14). Your project should be built using the latest version of the SDK as possible as long as it is 4.0 or newer.

Targetting API level 11 or newer is required as it will cause Android to automatically add the native action bar when run on newer devices. Since you will be compiling against new APIs but your app will likely be run on devices with older versions of Android extra care must be taken to either avoid using or properly check and call any methods that were introduced after your minimum SDK version.

The first paragraph shows that a build target that contains the 4.0 ActionBar API is required, as the library makes use of it and can't compile without it. The second paragraph shows that a target SDK that contains the 3.0 ActionBar API is required as the library uses the native ActionBar on such devices, but the Android system won't provide the ActionBar if your target SDK is lower than 3.0 since that tells it not to use anything newer than your target (like the 3.0 ActionBar).

Some references:

Build Target

Target SDK