It's slightly trickier then that. The action bar provides a lot of great features the android dev site has an extensive article on how to use it (http://developer.android.com/guide/topics/ui/actionbar.html). But you also have to bear in mind the common android dev issue of compatibility. Unfortunately 81% of the android devices are current are using 2.2 or 2.3 (http://developer.android.com/about/dashboards/index.html) which is what most developers build against. So, you will need to decided what your support strategy will be for 4.0+ users and 2.2 and 2.3 user who make up the bulk of the user base. The action bar is just one of the many features that you'll be unable to fully use on older devices. Others include direct wifi connective

It maybe that you release a 2.2 and 4.0 version of your app and maintain two codes bases. Or you use the compatiability back to provide limited support on legacy devices, or various other tricks.

For compatibility issues, isn't there a way to detect if the Android OS my app is being run on is a version older than 3.X?

I used to know that in C++, when you're programming for certain OS, you can use something like this (And yes, I do know my macros are incorrect, but the point is given):


#if __WINDOWS__
#elseif __APPLE__
#elseif __LINUX__
#endif


Would it be possible to code something like this for Android?

Those are compile time macros so you'd rather want something similar to getVersionEx on Windows.

http://developer.and...ld.VERSION.html should do the trick.

only annoying part is that the SDK_INT field is only available in newer versions (API versions 4+ (Android 1.6 and up) , and the RELEASE field is a string that may contain non numbers (it can be 4.1b3 for example). (There is also a deprecated SDK field but i wouldn't recommend using that).

If you don't care about 1.5 and down you can just use the value in SDK_INT to see what features you'll have available.

There are a couple of approaches you could take.

Google Play allow you to have multiple apk files for the same app targeting different devices or api versions. So you can build your app against 2.2 and then have a second version of it that is built on 4.0 that references the 2.2. version but has 4.0 specific versions of your UI. This requires good design practices around separating your ui code from your functional code generally know as an api layer.

Another option along a similar line which I came across the other day and I'm currently trying out on my current app is to use an api layer and a factory pattern along with custom widgets. The idea is that rather then use the action bar directly you refer to a custom action bar that provides all the same functionality but under the covers does
version checks and providers either the action bar or a customer built equivalent depending on what the device supports. There is a added complexity around this of course and does mean you may see ui differences between versions. You will also have to build against a newer version then you are supporting which means you have to have
extensive tests against older api versions.

Or you could also take a hard line design decision not support any features that aren't in 2.2 and 4.0

But not matter what you choose you should never ever have developers working on there own bits it what ever version they prefer. Everyone should be working against common set standards and guidelines otherwise things will become unmanageable. That includes api versions, coding standards, naming conventions, etc..

This is covered pretty well here: http://stackoverflow.com/questions/8774317/handling-the-missing-menu-button-in-new-versions-of-android-3-x-and-up