Question

I quote from the SDK docs:

“Beginning with Android 3.0 (API level 11), Android-powered devices are no longer required to provide a dedicated Menu button. With this change, Android apps should migrate away from a dependence on the traditional 6-item menu panel and instead provide an action bar to present common user actions.”

Further more:
“If you’re developing for Android 2.3 or lower, users can reveal the options menu panel by pressing the Menu button.
On Android 3.0 and higher, items from the options menu are presented by the action bar as a combination of on-screen action items and overflow options. Beginning with Android 3.0, the Menu button is deprecated (some devices don’t have one), so you should migrate toward using the action bar to provide access to actions and other options.”

So, if I understand correctly, on devices with Android 3.0 or higher, which do have a Menu button, the depraceted code will still work, while on device with Android 3.0 or higher and no Menu button, the depraceted code will not work.

5 questions arise:

1. Can these compatibility issues be handled through the Android compatibility library?
2. If yes, how?
3. If no, does anyone have a list of devices with Android 3 and higher and no Menu button?
4. How high is the market share of these devices currently?
5. Specifying a max SDK, will exclude all devices, no matter if they have a Menu butto or not. Is there are better way, to ensure an app is only installed on compatible devices?

Answer 1

Can these compatibility issues be handled through the Android
compatibility library? If yes, how?

Set your target API to 11 or higher (It’s recommended you set it to the latest available version: So, set your target API to 15). Then enable an ActionBar in your application. What used to show up via a menu key now shows up in the overflow menu of the ActionBar, or shows up as individual actions on the bar itself if you set each one’s “showIfRoom” true.

If no, does anyone have a list of devices with Android 3 and higher
and no Menu button?

Trying to code special cases is the wrong approach. On devices with a menu button, it’ll work with the menu button. On those without a menu button, there will be the overflow menu. There’s a blog post about this on the Android Developer Blog.

How high is the market share of these devices currently?

Small but growing.

Specifying a max SDK, will exclude all devices, no matter if they have a Menu butto or not. Is there are better way, to ensure an app is only installed on compatible devices?

Yes: The method I described will handle both scenarios, and it’ll work across all devices 🙂 No reason to use maxSdk.

EDIT: To address questions from the comments:

So, if my target is 8, the devices with 11 will not handle the Menu button properly?

If you set your target to less than 11, devices without a menu key will have a “legacy” menu button next to the other soft buttons, like here: http://android-developers.blogspot.com/2012/01/say-goodbye-to-menu-button.html

On the other hand, if I set target to 11, eclipse will not warn me, if I use features > 8?

If you set your target to 11 and min to 8, Eclipse won’t warn you if you use 9+ features- You’ll need to test your app for that. Easy way to do that: Move your target SDK temporarily back to 8, see where the compiler yells at you, make sure those code paths never get hit on devices that can’t handle them.

What consequences does it have for distribution on Google Play Market?

Only good ones. If you set a Max SDK, your application would be compatible with fewer and fewer devices as time went on. Having a min version of 8 (instead of scrapping backward compatibility alltogether) means your application is installable on Froyo and Gingerbread devices, instead of only Honeycomb and up.