Develop Reference

Layout according to android version

i am trying to make a alarm clock, the GlowPadView in the newer android versions it quite good looking and i was planning to use that in my application, but at the same time i also want to support 2.3.3(Gingerbread) which still has a major chunk of phones. So i was wondering if there is a way that i can check the android version the phone is running and show the layout according to that. If the phone is running API 11 + the layout shows GlowPadView otherwise it shows basic swipe views from the Gingerbread stock alarm application.
To check the android version Build.VERSION_CODES can be used
android.os.Build.VERSION.SDK_INT;

So i was wondering if there is a way that i can check the android version the phone is running and show the layout according to that.
Create separate directories, such as res/layout/ and res/layout-v11/. Have the same-named layout resource in each (e.g., foo.xml), and put the GlowPadView in the foo.xml that you place in res/layout-v11/.

As you stated, you could just create two completely separate layouts, and then have an if (android.os.Build.VERSION.SDK_INT > 11), setContentView() to one layout and if (android.os.Build.VERSION.SDK_INT<=11) setContentView() to a different layout.

Android Home Screen Widget with SDK version 11 or above Only

I am working with the application minimum sdk version 3. I want the app to support Home Screen widget with OS 3.0(sdk - 11) or above only. i.e. User with OS 3.0 or above only should be displayed in widget. How to do the same ?
I already asked one more question let me know if its possible too.
How to get Number of records displayed in RemoteView

Solution 1:
Publish 2 APKs:
One with android:minSdkVersion="11" in your manifest and with your widget implementation
The other one with android:minSdkVersion="3"in your manifest and no widget implementation
Solution 2:
Keep minSdk 3 (android:minSdkVersion="3") and check the SDK version in both methods onUpdate and onReceive of the class that extends AppWidgetProvider. Do the job only if Build.VERSION.SKD_INT >= 11.
In the same way, if you have a App Widget Configuration Activity, do the following in onCreate():
if (Build.VERSION.SDK_INT < 11) {
setResult(RESULT_CANCELED);
Toast.makeText(this, getString(R.string.widget_error_cannot_be_installed), Toast.LENGTH_LONG).show();
finish();
}
Just keep in mind that users with OS<3.0 will see the widget in their widget gallery but will not be able to add it. So you might show a Toast something like "Your Android OS version is too low to add widget".
Let us know if you find any other solution.
Thanks

I am facing same type of issue.
Solution:
if android os version 2.2 or lower then make static list of your data.
else you have to implement listview and set all contain.
If you find any trouble then let me know.

1) You can check OS version with Build.VERSION.SDK_INT, compare it to version codes defined in Build.VERSION_CODES.
2) Keep in mind that on OSes before 2.0 (If i remember it correctly) ClassLoaders are very angry about any 'not supported' classes or methods mentioned in any methods of a loaded class, even if you never actually call these methods. So be sure you don't import anything not available on 1.5 in classes that will be used in 1.5 .

Setting values in AndroidManifes.xml

Is it possible to set values in AndroidManifest.xml by code?
For example I want to set android:largeHeap="true", but it is possible only in 3.x platforms; but my application must run on 2.2 and above.
Then I want to set android:largeHeap="true" on 3.x platforms and do nothing on 2.x platforms by code.
Any ideas??

It is NOT possible to change Manifest at runtime..
from developer.android.com :
The manifest presents essential information about the application to
the Android system, information the system must have before it can run
any of the application's code.
plus:
These declarations let the Android system know what the components are
and under what conditions they can be launched.
so everything is specified before running and then your App runs, under permissions and conditions Android system gave to it.
cheers

Android compatibilty settings in AndroidManifest.xml

I have an app to release which works on all android screen-sizes (except smaller) and densities above SDK version 2.0.
It will also run on extra large screens.
Currently I have added this:
<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="false"
android:anyDensity="true"
/>
But I also need to add android:xlargeScreens="true" , to allow it visible in android market on extra large screen devices, since by default it is false.
But to add android:xlargeScreens I need to change my eclipse targetsettings to 2.3 as this attribute was added from API level 9.
So what should I do with my target compilation settings for this scenario ? Should it be 2.3 while compiling ? If yes, then will the app not give any problems while running on devices with 2.0 version ?

Yes you need to change the uses sdk to 2.3 but make sure that you are not using any newer apis which are not in 2.0 or whatever your minimum supported sdk version is. Or in case you want to use them you have to use reflection.
But more about how to use the sdk versions is here and more about uses-sdk is here.
I do the same in my application and make sure you test your application in both[all] the versions before you release.
Best,
Achie.

I'm moving this from the comments to make it more clear for others looking at this question in the future.
When supporting both old and new versions of Android it can be confusing how applications manage to run despite many things change with in the frameworks during each new release, I'm going to try and clarify this here.
An application written for the 1.5 sdk can only call functions that exist for that API level, so for instance the multi touch api's didn't exist in 1.5 and never will. Now you say "Ok but I don't need to call any newer APIs, I just want my app to work in 2.3 and have a2sd support" And I say "Ok, just change your targetApi in the manifest, set the minSDK and compile against 2.3 and you're good to go."
Now why does that work? What if the onMeasure() method for ListView was changed in 2.2 and now calls betterCalculateFunction() within onMeasure()? Why does my app still work?
This is the advantage of late binding in Java. You see, Java is never compiled until it reaches a device and is running, what you are doing in Eclipse is converting it to byte code which contains a bunch of byte code instructions that are later interpreted by the device. The byte code will NEVER contain a reference to betterCalculateFunction() though (unless you directly call it. Calling onMeasure() is indirect). This can happen because when your code is running on the device it gets linked against the Android framework on the device and your code calls onMeasure() directly because it is a public outward facing API. The path of execution will then enter the framework and call whatever it needs to, then once its done return to your code.
So on 1.5 you might see
doStuff (your code) -> onMeasure
(public API) -> done
and 2.2
doStuff (your code) -> onMeasure
(public API) ->
betterCalculateFunction (private
function) ->done
Now if you need to call functions that may or may not exist depending on API level then I suggest you look at a related answer of mine here stackoverflow: gracefully downgrade your app
Hope that clears some things up.

I haven't tried 2.3, but that's what I do with 2.2.
I compile for 2.2 and test on 1.6 to make sure everything works how I'm expecting. I haven't run in to any issues with it.
To double check, set your target for 2.3 and then setup an emulator for a lower rev version to make sure it all works.

The default value for android:xlargeScreens is true, so you don't have to change anything - it's on by default, as long as your minSdkVersion or targetSdkVersion is higher than 4.
http://developer.android.com/guide/topics/manifest/supports-screens-element.html

Here is an official Android developer blog explanation of how this works:
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
In summary: you can use the newest XML whilst still supporting the older OS versions in a back compatible way.

While reading this blog post I guess I have an answer on my old question. An extract below (which is for another manifest attribute "requiresSmallestWidthDp" introduced from 3.2):
"The catch is that you must compile your application against Android 3.2 or higher in order to use the requiresSmallestWidthDp attribute. Older versions don’t understand this attribute and will raise a compile-time error. The safest thing to do is develop your app against the platform that matches the API level you’ve set for minSdkVersion. When you’re making final preparations to build your release candidate, change the build target to Android 3.2 and add the requiresSmallestWidthDp attribute. Android versions older than 3.2 simply ignore that XML attribute, so there’s no risk of a runtime failure."

For different screens you have to create multiple apk then it reduces size of your application.In each application's manifest you have to define according to following link.
http://developer.android.com/guide/practices/screens-distribution.html

How to re-build the default "Launcher" application?

My goal is to modify the Launcher application and dynamically modify and change the theme.
I saw several 'home' apps at http://www.cyrket.com/p/android/com.stain46.taghome/. It looks like they took the default Home(Launcher) and modified it. How did they do that? What do I need to modify to achieve the same thing?

I have done this with the ICS launcher. You also need to do quite a number of code changes to get it to compile as a normal app because it uses a lot of private internal APIs (despite what Google may have implied). You also need to change the package name. There are two limitations I've found:
There's a filter called TableMaskFilter that isn't available to normal apps. I think this allows the app drawer to be semi-transparent, but I removed uses of it and it looks fine I think.
More critically, it appears there is no way to replicate the widget-adding experience because it requires a permission that only system apps can have. See this question.
Anyway, I put my source here. It compiles and works on the official Galaxy S2 4.0.3, but if you try to add widgets it will crash.
Note, when you're changing the package name, there are places that Eclipse's refactor doesn't notice (e.g. XML layouts). I recommend you do a global text search/replace instead.

The standard Launcher is open source so you can definitely grab it and modify it the way you want. For your app to be used as the Home Screen you will need to specify the correct Intent filter in your AndroidManifest.xml and the user will have to choose your app when they press the Home button. Why don't you grab that code, play with it and come back when you have more questions and more of an idea of what you want to change.

Here i found one stable version Launcher2
I have sharing that GitHub repo. HERE
WIKI of this project :
This project contains the code for the Launcher app that ships with Android Jelly Bean (API 16).
Some minor changes were required from this source code to remove the use of private APIs. These changes have been marked by "// AOSP Change"