Develop Reference

Android - multiple SDK support in one project?

I'm creating an app that uses the clipboard manager. Since the way of working with this has changed since API level 10 but I still want it to work on all versions, I would like to use both APIs if possible. I would then like to code some kind logic like this:
if androidVersion < 10
use code x
else
use code y
Is this possible?
When I create a project in Eclipse, it either gives me the Android 1.6 jar file or the Android 3.0 jar file depending on the min SDK version I selected. My question is if it's possible to import and use both and if so how? Or will I simply need to make separate projects for different versions? Thanks.

Is this possible?
Sure. Use android.os.Build.VERSION to find out what version you are running on and use the appropriate code based upon that.
If you are supporting Android 1.x, the story gets a bit more complicated.
When I create a project in Eclipse, it either gives me the Android 1.6 jar file or the Android 3.0 jar file depending on the min SDK version I selected.
No, it does not. It gives you 1.6, 3.0, or whatever based on the build target you selected. By default, it also makes the android:minSdkVersion match that, but you can change that, so the minSdkVersion is the oldest that you are willing to support and the build target is the oldest whose APIs you are directly referencing.
My question is if it's possible to import and use both and if so how?
You do not need to import both, and you can't do that anyway.
Or will I simply need to make separate projects for different versions?
You do not need separate versions.

Difference between targetSdkVersion and Project build target

What is the difference between targetSdkVersion set in the Manifest file and the Project build target set in the building environment (e.g. Eclipse) ?
I have tried to find more information on these two features, but I couldn't find any clear and specific explanation.
It seems like the Project build target decides on the API compatibility level, to be used during the compilation. When the targetSdkVersion only affects the visibility of the manifest elements of the given API level.
Could anyone confirm/expound this?
EDIT: Thanks guys for prompt responses. I forgot to mention in my question that I have read all the topics on Android Dev regarding these features and also googled it and searched it on Stack Overflow. So I understand the basic purpose of min/target/maxSdkVersion to be used in Android Market and in the Android System itself. However, according to other posts from people having problems with this Manifest option, it seems uses-sdk does actually have impact on how the the API level is interpreted. At least that is what I suspect.
A really good explanation is given here:
http://developer.android.com/guide/appendix/api-levels.html
However, it is still unclear for me whether the targetSdkVersion does affect the compilation/runtime of the APK on Android System? Or it is only for validation as the uses-sdk documentation suggests?

The targetSdkVersion attribute does indeed affect an application's runtime behavior.
Depending on what you set it to will determine whether compatibility features are enabled/disabled in the Android framework.
For example, once you set targetSdkVersion=11, your application's default theme will be set to #android:style/Theme.Holo -- meaning your application will have a Honeycomb-style UI widgets, will get an Action Bar, and will not have an Options Menu button at the bottom of the screen.
If you set targetSdkVersion to a lower value than, your default theme will continue to be #android:style/Theme -- regardless of which API level you're actually building against.
The targetSdkLevel also affects what the default values are for the <supports-screens> element, which in turn will determine whether your application runs in density compatibility mode.
Interesting note: Android Market doesn't actually use the targetSdkLevel attribute for anything at the moment. It's purely used at runtime for compatibility purposes, and possibly at compile time -- though I haven't looked into the behavior there. If people are curious about the compiler, I could check with the SDK team to get more information.
Of course, it's entirely possible that Market could decide to do something with this in the future.

The Build Target is used to know which SDK to compile your APK with. This means that if there are any Classes or methods that aren't available in your min SDK version, but are in versions after that, those Classes or methods will still be available to use. You will just have to make sure to check when you're using those and do alternate approaches if the user's SDK version isn't compatible with those classes/methods.
android:targetSdkVersion
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.
You can find more information by referring to this URL:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
There's also a good article written by google on checking to make sure you're current users Android OS version will use the appropriate Classes/methods
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html

In your "Create Project"-dialog in Eclipse, you specify the minSdkVersion. This is the API-Level that is required to run your application.
The targetSdkVersion-attribute only tells the Android Market that your App was developed (and maybe optimized) to run under the specified API-Level.

Build target is the one on which you will be testing the app. targetSdkVersion is the one your app was specifically developed for. Both are same most of the times.
You will find a detailed explanation here.

targetSdkVersion attribute informs the system that you have tested your app against the given version (api level) and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. The application is still able to run on older versions (down to minSdkVersion).
For further detail - http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

This question has already been adequately answered, but I want to point out that it is no longer entirely correct that the Google Play store does not use targetSdkVersion at all.
In the specific case where you set targetSdkVersion to 23 (Marshmallow 6.0) and upload your APK, even if you are uploading a Beta version, you will not be able to ever again submit an APK for that app that has a lower targetSdkVersion than 23.
This is because of changes to permissions between 22 and 23 which are not allowed to be reversed for a given app.
This can be a bit of a trap if you were just trying out 23 in Beta and not sure you were ready to support it yet.

Converting Android version 2.3 to 1.5

I have developed one application in Android version 2.3, and want to convert it into 1.5.
Unfortunately I am experiencing some problem with that.
I have changed minSDK from 8 to 5
changed from property
But I still get the problem.
Any ideas?

There are several aspects to converting an application's version number.
The later the Android version, the more features are supported. Features are things like front-facing camera support, NFC support, Fragments or Drag and drop.
If you plan to convert an application, make sure that the target version supports the features you need. This describes the major differences between the various API levels.
The Android API is updated with each new Android version. This means that methods, constants and attributes can be available on some API levels, but not on others. To see what is available in which API level, go to the android documentation and in the upper right corner select 'filter by api level'. Then select an API level. After you do that all API features that weren't available in the selected API level will be grayed out making it easy to identify the available elements. If your code contains elements that don't exist in the targeted level, you will get errors.
You need to explicitly specify the Android version in two(!) places in Eclipse.
To change the API level of an Android project in Eclipse:
a. Open the project manifest and change the minSdkVersion:
b. Open Properties -> Android, and change the Project Build Target (API level).
Finish by cleaning your project (Project -> Clean...) to ensure that the project references are updated.
After doing this, any features (methods, constants, attributes, etc.) not available in the updated API level will show up as errors in your project.
To fix these errors, Google
android < feature> < API level>
which will often lead you to replacement code.
After re-reading the question I believe I've found the specific mistake:
You say you've set the minSdkVersion to 5. API level 5 corresponds to Android version 2.0.
You also say you want to convert your project to Android version 1.5, which leads me to believe that you've set your Project Build Target to the corresponding API level 3.
If you change either of those to match the other, your original problem should be solved.

In order:
change the minSDKattribute in your manifest
edit project properties and change the target platform, to ensure you rely on the good library
do a Project > Clean to ensure, to ensure you don't have old constants in R.java or binary code compiled for a future platform
fix your project
optionnaly, place back some future code, like move to SD feature in the manifest

To convert backward means that you have to write alternative code to replace method for api you used in the higher version SDK=8 that aren't supported in the old SDK=5, because in the old version those methods won't exist.
It is better if you plan ahead witch minimum version to support.

Right click the project in eclipse, go to Properties, go to android, and set the build target to 1.5.

If you have used any inbuild functions or methods or constants or attributes that was added after the release of android 1.5 and if you try to change to 1.5 now, you will not be able to do that. Make sure that you have not used such kind of methods or any other attributes that was not released in 1.5.

Support 3.0 and lower levels in the same project

I have a level 9 app on android, and I want to know if I can use new features from level 11 (Android 3.0) in the same project?
For 3.0 tablet version, my layouts will contain fragments. How do I use these fragments and allow the level 9 version to build and run successfully?
Can I define different layouts for different API levels (in the res/layout)?
If I keep 2 versions, one for tablet other for phones, can I add that to the android-marketplace with the same package name?

I have a level 9 app on android, and I want to know if I can use new features from level 11 (Android 3.0) in the same project?
Yes, via reflection or conditional class loading, as suggested by Mr. Willis. Here is a sample application that demonstrates this for the action bar, also new to API Level 11.
For 3.0 tablet version, my layouts will contain fragments. How do I use these fragments and allow the level 9 version to build and run successfully?
Use the Android compatibility library.
Can I define different layouts for different API levels (in the res/layout)?
Yes, via the -vNN resource set suffix (e.g., res/layout-v11). However, you should try to minimize this.
If I keep 2 versions, one for tablet other for phones, can I add that to the android-marketplace with the same package name?
No.

This question and answers seem helpful.
The official documentation also overs solutions in Backward Compatibility for Applications.
Try: http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html
Using reflection is advised, which allows you to programmatically search for the existence of classes and methods at runtime.
As for layouts, try checking out Supporting Multiple Screen Sizes. There are different layout sizes such as layout-xlarge that you can use.
If I keep 2 versions, one for tablet
other for phones, can I add that to
the android-marketplace with the same
package name?
You can't use the same package name for two different apps.
If your code is sufficiently different depending on the API version you're using, you might want to fork your code and then merge it again later when you are confident most of your user base has upgraded to the API level you need.

Confused about Android API's and compatability

I have purchased an HTC Incredible and have dived into the world of android! Only to find myself totally confused about the API levels and backward compatibility.
My device runs the 2.1 OS, but I know that most of the devices out there run 1.5 or 1.6; and soon the 2.2 OS will be running on new devices. The SDK has gone through such enormous changes, that even constants have been renamed (from VIEW_ACTION to ACTION_VIEW for example). Methods have been added and removed (onPause replacing the earlier call, etc al).
So, If I want to write an application that will work from 1.6+, does that mean I have to install and write my code using the 1.6 API; then test on later versions? Or can I write using the 2.1 SDK and just set the minSDK level and not use "new" features?
I have never worked with an SDK that changes SO drastically from release to release! So I am not sure what to do....
I read through an article on the Android Development site(and this posting on stack overflow that references it: Should a legacy Android application be rebuilt using SDK 2.1?), but it was still not very clear to me.
Any help would be appreciated

The SDK has gone through such enormous
changes, that even constants have been
renamed (from VIEW_ACTION to
ACTION_VIEW for example). Methods have
been added and removed (onPause
replacing the earlier call, etc al).
Those were two years ago, on a beta version of the platform, before there were any shipping devices. Since Android 1.0, there has been very little that breaks forward compatibility, mostly in the area of settings that were moved into a secure API so SDK applications cannot mess with them.
So, If I want to write an application
that will work from 1.6+, does that
mean I have to install and write my
code using the 1.6 API; then test on
later versions? Or can I write using
the 2.1 SDK and just set the minSDK
level and not use "new" features?
You make it seem like those are mutually exclusive. In fact, they are largely identical.
Keep your toolset on the latest version of the Android development tools
Put the minSdkVersion in your manifest to state what is the lowest API level you want to support
Put the targetSdkVersion in your manifest to state what your "target" API level is, so Android can apply some compatibility helpers if your app runs on a newer version of Android (typically, you "target" the then-current API level)
Write your code mostly to the API level you specified in minSdkVersion, optionally using reflection or conditional class loading to access newer APIs on devices that support them
Test on everything you can get your hands on, at least emulators for the different API levels

You can use the current SDK and set minSDK level to whatever level you want. If you do this then you cannot use any functionality that is not in the minSDK. It is also a good idea though to test it on all versions of the SDK with the emulator.
<uses-sdk minSDK="4" targetSDK="8"/>
That lets it know that you are targeting 2.2 but the minimum SDK level you want your app to run on is 1.6. By doing that you can use some of the new xml stuff in the newer versions like supports-screen and different drawables for different screens, etc.