Develop Reference

Can I develop different layouts( UI ) for gingerbread, ICS and Kitkat for the same app?

as I saw that some new APIs were came in ICS which is not available in gingerbread ,but I want to use this in my app and I want my min sdk version also 2.3, how can I do this ?
Can I develop two different user interface for the two different version of android in the same app.
like we can develop UI for different screen sizes by using layout-sw600dp or whatever we want ?

Use the -vNN resource set qualifier. res/layout/ would be used by default; res/layout-v11/ would be used by API Level 11+ devices; res/layout-v14/ would be used by API Level 14+ devices; etc.

Android load different layout according to OS

My supported OS versions are >= 2.2
Now i want to use some >= 4.0 views in my application, So whats the best way to load different layouts according to different os? say I want to use default time picker in android os < 4.0 and holo theme time picker in android >= 4.0
Is it possible? whats the best way?

See this article.
Basically you can define different layouts per API level (and many other qualifiers). In your case, you would have:
res/layout/my_layout.xml (with the "old" controls).
res/layout-v15/my_layout.xml (with the "new" controls).
A device with API level 15 (i.e. ICS) or greater will use the "new" layout, while those with a lower API level will use the other one.
To simplify your code (e.g. usage of findViewById()) make sure that corresponding views in both layouts have the same ids.

What's the difference between layout-large-v11 and layout-xlarge

I'm working on a Tablet application.
What's the difference between this two res folders: layout-large-v11 and layout-xlarge?
The first option is from the IOSched app.
Are both valid for tablets? Which one is better for design tablets layouts?
Many thanks for the help.

v11 is there to help distinguish between large devices that are still running older versions of android. This distinguishing is necessary because there were some big changes at Android 3.0 (version 11 of the api), in terms of style. So the v11 allows you to say "Ok, if this is a newer version of android, use this newer style of layout, other wise use this older style".
Bottom line, you only need to use it if you want to provide two different layouts: one for versions of android that are pre-3.0, and one for versions that are post-3.0. v11 actually has nothing to do with the size of the screen itself, merely what version of android you're running on.

Android dalvik problem

Please i have different platforms installed. I just wanted to know what am supposed to do. If i develop with 3.0 platform, would those with a 2.2 be able to use my app??..
The second question which is the main question is I always get this error when i create android projects..
[2011-05-16 16:32:21 - Hello World] Dx no classfiles specified
[2011-05-16 16:32:21 - Hello World] Conversion to Dalvik format failed with error 1
What do I do to it?

There are several reports out there for that error (e.g., this one. All the solutions point simply to reload the project (select it in the tree at your left, and press F5).
Regarding the first question, unless you want to support Honeycomb-only features, then set up the api level to 8 (Froyo).
Eclair, Froyo and Gingerbread are android versions 2.1, 2.2 and 2.3 respectively (also referred in the documentation as API levels 7, 8 and 9). See the table here. If you want to support just mobile phones, set your target to 2.1 or even lower. That way you will be able to target most of the phones in the market. Your app will also run in Honeycomb (3.x) devices.
Honeycomb has new features to support larger screen devices, so if that is your main target, you might consider taking advantage of those features and drop cell phone support. All will depend on what is your objective.

you should have a look at the minSdk and targetSdk features of a manifest file :
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="8" />
This will help you target a android sdk version and precise what is the minimum sdk level that can run your app.
Regards,
Steff

Developing for Honeycomb or non-tablet version of Android, is different in various things. Your 2.2 application should run correctly on a tablet, but if you want to optimize the graphical interface and use all the notification and other things included only in Honeycomb, then you must use the appropriate API. Until Ice Cream Sandwich is released, we have to develope two different application for the best result.
Regarding the error you get with android projects (I suppose under eclipse?) you'll find some detail at this link, but if you follow all the instruction provided by google in the developers page, you'll be able to write and run your Hello World application.

Android - how to design an app that targets all platforms (1.5 and higher)

I have been developing an Android app and testing with a 1.5 AVD and the manifest setting of
<uses-sdk android:minSdkVersion="3" />
My goal is to make this app available to all phones running 1.5 and greater. I had thought that as long as I develop to 1.5 then that was basically all I had to worry about and any phone running 1.5 or higher would see my app in the market and be able to install it. The following documentation however has me concerned that the app may not in fact be visible to all phones in the market unless I go through the following steps to manage various screen sizes and densities.
My layout is very basic and I do not manage any alternate layouts for high resolution, I just let android manage the scaling. Do I need to follow these guidelines in order to have my app visible to all phones 1.5 and higher? Or is this only necessary in certain circumstances?
From
http://developer.android.com/guide/practices/screens_support.html
Strategies for Legacy Applications
If you have already developed and published an Android application based on Android 1.5 or earlier platform version, you need to consider how you will adapt your application so that it is deployable to
* Existing devices, which may be running Android 1.5 (or lower) platform version, as well as to
* Newer devices that are running Android 1.6 (or higher) and offering various screen sizes and resolutions
To support the newer devices and the different screens they use, you might need to make some changes in your app, but at the same time your app may be very stable and so you want to minimize the changes. There are a variety of ways that you can extend your existing application to support new devices with multiple screens and existing devices running older platform versions. You should be able to make these changes to your application such that you can distribute a single .apk to any and all devices.
The recommended strategy is to develop against the most recent version of the platform you are targeting, and test on the minimum one you want to run on. Here's how to do that:
1. Maintain compatibility with existing devices by leaving your application's android:minSdkVersion attribute as it is. You do not need to increment the value of the attribute to support new devices and multiple screens.
2. Extend compatibility for Android 1.6 (and higher) devices by adding a new attribute — android:targetSdkVersion — to the uses-sdk element. Set the value of the attribute to "4". This allows your application to "inherit" the platform's multiple screens support, even though it is technically using an earlier version of the API.
3. Add an empty <supports-screens> element as a child of <manifest>. If you need to enable size or density attributes later, this is where you will add them.
4. Change your application's build properties, such that it compiles against the Android 1.6 (API Level 4) library, rather than against the Android 1.5 (or earlier) library. You will not be able to compile your application against the older platform because of the new manifest attribute.
5. Set up AVDs for testing your application on Android 1.6 and higher releases. Create AVDs that use the screen sizes and densities that you want to support. When you create the AVDs, make sure to select the Android 1.6 or higher platform as the system image to run. For more information, see How to Test Your Application on Multiple Screens, below.
6. Set up AVDs for testing your application on Android 1.5 (or earlier platform). You need AVDs running the older platforms you are targeting, so that you can test for compatibility and ensure that there are no functional regressions.
7. Compile your application against the Android 1.6 library and run it on the AVDs you created. Observe the way your application looks and runs, and test all of the user interactions.
8. Debug any display or functional issues. For issues that you resolve in your application code, make certain not to use any APIs introduced in API Level 4 or later. If you are in doubt, refer to SDK reference documentation and look for the API Level specifier for the API you want to use. Using an API introduced in API Level 4 or later will mean that your application will no longer be compatible with devices running Android 1.5 or earlier.
9. For resource-related issues, you can try resolving them by:
* Adding a anyDensity="false" attribute to <supports-screens>, to enable density-compatibility scaling.
* Creating any size- or density-specific resources you need and placing them in directories tagged with the correct qualifiers. Qualifiers must be arranged in a proscribed order. See Alternative Resources for more information.
* Note that if you add size- or density-specific resource directories tagged with any of the resource qualifiers listed in this document, you should make sure to also tag those directories with the v<api-level> qualifier (for example, -v4). This ensures that those resources will be ignored when the application is run on Android 1.5 or lower platform versions.
10. If your application does not offer support (such as custom layouts) for large screens and you want the platform to display your application in screen-compatibility mode on larger screens, add a largeScreens="false" attribute to the <supports-screens> element in the manifest. See Screen-Compatibility Examples for illustrations of how the platform displays your application in this case.
11. If your application does not offer support (such as custom layouts) for small screens (such as on a QVGA low-density screen) and you do not want Android Market to offer the application to users of small-screen devices, you must add a smallScreens="false" attribute to the <supports-screens> element.
12. Continue testing and debugging until your application performs as expected on all of the platforms and screen sizes your application will support.
13. Export, zipalign, and sign your application using the same private key you used when publishing the previous version, then publish the application to users as an update.

From this answer:
Save your keystore file.
If you lose it, you will not be able to update your app.
Use <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/> to be compatible with 1.5 and newer devices.
Make your icons based on the Icon Design Guidelines.