I have a question about the build target of an Android app. The minSDKVersion is clear, if specified your device needs to run on at minimum that OS level, otherwise the app won't install. However, the build target is a bit more foggy in my view...
From the API docs:
An integer designating the API Level that the application is targetting.
With this attribute set, the application says that it is able to run on older versions (down to minSdkVersion), but was explicitly tested to work with the version specified here. Specifying this target version allows the platform to disable compatibility settings that are not required for the target version (which may otherwise be turned on in order to maintain forward-compatibility) or enable newer features that are not available to older applications. This does not mean that you can program different features for different versions of the platform—it simply informs the platform that you have tested against the target version and the platform should not perform any extra work to maintain forward-compatibility with the target version.
Introduced in: API Level 4
If e.g. I build a Google Maps app, which only uses basic features which are present since v1.5 (API level 3). The minSDKVersion is 3, but what should I set the target version to? Always the latest API level? Anything else? Why?
I had to implement the "android:targetSdkVersion" in my application to get rid of a force close issue during the creation of a AsyncTask(). No idea why, but simply adding that statement to the manifest with a value of "4" fixed my issue. Here's the great part; it really should be "3" as that's also my minSdkVersion, but the syntax for targetSdkVersion wasn't introduced until 1.6.
When you add the targetSdkVersion it means your application will use, in my case, the 1.6 libraries to compile, again in my case, code that is compatible with 1.5. Sounds scary? Is. For me at least. I went through extensive testing after making the change.
# This file is automatically generated by Android Tools.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
# This file must be checked in Version Control Systems.
# To customize properties used by the Ant build system use,
# "build.properties", and override values to adapt the script to your
# project structure.
# Project target.
Is the default.properties file superseeded by the targetSdkVersion attribute and is it still being generated for backwards compatibility?
So it should be the case that if your app is deployed to a device that matches the target SDK, the user should have no problems. If you want the same app to run on older versions of Android, this is possible by specifying a lower version number for the min SDK. But now you have to be prepared to handle any class differences that exist in stuff you're using in your app. The reason you might target a higher version than the min is that you might want to take advantage of a feature that exists in the higher version, while gracefully handling the case when a class or method doesn't exist in an older version. We cover this in our book in a few places as well. You can look at the actual build value for the device you're on and take appropriate action, or you can use reflection to figure out if what you want to do can be done or not, and take appropriate action if not.
To answer the other part of your question, the AndroidManifest.xml file is really used by the Android Market and devices you're deploying to. The default.properties file is for Eclipse and the build process. They should be in sync. As it says in the reference page, the targetSdkVersion can be used by a device to determine if it needs to employ compatibility features or not.
Thanks for the answer. Helps a lot!
I guess it boils down to this:
. If you want the same app to run on older versions of Android, this is possible by specifying a lower version number for the min SDK. But now you have to be prepared to handle any class differences that exist in stuff you're using in your app. The reason you might target a higher version than the min is that you might want to take advantage of a feature that exists in the higher version, while gracefully handling the case when a class or method doesn't exist in an older version.
And that probably comes with experience?! I hope I win the book so I can take a look at the examples your hinting at ;-)