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...
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?
Johan Pelgrim, The Netherlands
SCJP 1.4, SCWCD 1.4, SCBCD 5.0
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.
To add to the confusion, Eclipse creates a default.properties files with e.g. this type of content
# 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?
Fun, isn't it? That default.properties file is there for Eclipse, not really for your build app. Bill is correct that the target SDK value is to specify which version of the libraries to build against. When deployed and running, if your app can't find a class, or method, it's looking for on the device, you'll get a crash (unless of course you handle the exceptions appropriately). The min SDK value is used by the Android Market and the Market app to know what apps can be downloaded to a device. So if the min SDK on an app says 8 (corresponding to Froyo 2.2), devices running pre-2.2 Android won't see the app.
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.
. 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 ;-)
Joined: Feb 04, 2010
My "experience" was a trial by fire aka Force Close issue. One of the recommended solutions was to add the Build Target tag. I set that equal to my minSDKVersion of 3, but that threw a syntactical error for my manifest. That's when I found that I needed to set the Build Target to 4 (v1.6) but I was still compiling to 3 (v1.5). Ahhh, the joys of software development.
Actually, all our sample projects are in source code you can download from our website: http://www.androidbook.com/projects. One of the links on this page will take you to the zip files (by chapter). There's another link that has step-by-step instructions on how to import our projects into Eclipse.