43

I'm currently struggling with this issue. I need to check if the device, where the app is installed, has a hardware menu key. Because it is not existing on some devices like Galaxy Nexus, I'm showing it directly in the UI in this case.

I have already looked at PackageManager.hasSystemFeature(), but didn't find anything useful there.

Has anyone already done this?

Sankar V
  • 4,794
  • 3
  • 38
  • 56
NiThDi
  • 1,007
  • 1
  • 9
  • 22
  • Hi. Thanks for your answer.I want to get around using the action bar because it steals to much space in my opinion. On Galaxy Nexus I can display a menu button in the UI, but this button gets unnecessary when you have a Nexus S with ICS, because the Nexus S has a hardware menu button. – NiThDi Jan 28 '12 at 17:31
  • Better resolution http://stackoverflow.com/questions/16092431/check-for-navigation-bar – Gelldur Oct 01 '13 at 22:43

6 Answers6

92
ViewConfiguration.get(context).hasPermanentMenuKey()

See ViewConfiguration#hasPermanentMenuKey() for more information. Note that this is only available for API level 14+ (Android 4.0 Ice Cream Sandwich or newer).

Nic
  • 6,211
  • 10
  • 46
  • 69
fhucho
  • 34,062
  • 40
  • 136
  • 186
  • 11
    Available only on API Level >= 14 http://developer.android.com/reference/android/view/ViewConfiguration.html#hasPermanentMenuKey() – Palani Jun 26 '12 at 08:15
  • 1
    On API 11 - 13 you can presume that MENU is not present. – fhucho Jun 26 '12 at 11:03
  • 1
    @fhucho This doesn't really help me. I need to support API level 10 upwards, so Eclipse raises an error if I try to use this. I want to draw the user's attention to overflow menu items by issuing a toast when there is a hardware menu key and hence no overflow menu on the Action Bar. It's really annoying that the overflow menu icon is not always shown regardless of whether there is a hardware menu key or not. (I don't understand your last comment, by the way.) – Jeff G Nov 11 '12 at 13:35
  • 4
    You need to set your build target to API level 14, that should stop Eclipse from complaining. In your code, check what is the API level. If it's 10 and less, the device does have hardware menu button. If it's 11 - 13 (Honeycomb), the device doesn't have HW MENU button, because tablets with Honeycomb doesn't have MENU. If the API level is 14 or higher, you can use hasPermanentMenuKey(). – fhucho Nov 11 '12 at 15:08
  • 4
    For reference, I have an API 14 device (with 4.0.3) with a hardware menu key and `hasPermanentMenuKey()` reports false. Insert frowny face here. – David Given Feb 07 '13 at 16:44
  • Simplified guidelines taking into acount real-life problems and not just theory: For API levels 1-10 you can rely on the menu button being present. For API levels 11+ you should assume that the menu key might not be present, but implemented it just in case it exists. – cprcrack Apr 20 '13 at 14:55
  • 1
    Do all API 10 and less have HW menu keys? What about the kindle fire and nook? – paul Oct 17 '13 at 18:44
  • Weirdly enough, this is accepted answer with 75 votes, and exactly the same one has -1 http://stackoverflow.com/a/16107945/900608 – Damian Walczak Apr 15 '15 at 14:50
  • @DamianWalczak what answer you mean exactly? – fhucho Apr 15 '15 at 17:33
  • In this thread accepted answer is ViewConfiguration.get(context).hasPermanentMenuKey(), which in other threads gets minused out... – Damian Walczak Apr 16 '15 at 09:40
  • But I did linked it in previous comment: http://stackoverflow.com/a/16107945/900608 – Damian Walczak Apr 16 '15 at 12:47
  • @DamianWalczak: It's the same answer, but posted to a different question - where it is the wrong solution. – Bergi Jul 21 '15 at 02:02
  • Tested on several devices, for me it works only in the following configuration: `return !ViewConfiguration.get(context).hasPermanentMenuKey() && !KeyCharacterMap.deviceHasKey(KeyEvent.KEYCODE_BACK);` – Johnny Cosmic Oct 05 '16 at 09:12
23
if(Build.VERSION.SDK_INT <= 10 || (Build.VERSION.SDK_INT >= 14 &&    
                              ViewConfiguration.get(this).hasPermanentMenuKey()))
{
   // menu key is present
}
else
{
  //No menu key
}
TheMan
  • 703
  • 8
  • 11
  • this is incorrect. for APIs lower than 11 , it will crash since it can't call the "hasPermanentMenuKey()" function . that's because it exists from API 14 and above. – android developer Aug 22 '13 at 11:49
  • 7
    As far as I can tell, it won't call hasPermanentMenuKey() because the check >= 14 will fail and call will not be made. That said everytime I use an API specific method, I always create a method xxV14() to handle it so that I can properly ignore the warning without worrying about other calls not being taken care of. – 3c71 Aug 25 '13 at 16:02
  • Yes, `Build.VERSION.SDK_INT >= 14` would have to be true in order for the rest to get evaluated. Note that Honeycomb (API 11–13) was available on tablets only, and they were not expected to have a menu button. Thus, if your aim is to decide whether or not to show a menu button in the UI, this code should work on all API versions. The only undesirable effect would be if you ever were to encounter a Honeycomb tablet with a physical Menu button (not sure if any exist), and the issue would just be cosmetic. See also http://android-developers.blogspot.de/2012/01/say-goodbye-to-menu-button.html. – user149408 Nov 05 '15 at 18:06
3

Even on devices running Honeycomb and later, the system will supply a “Menu button” for apps written for 2.x versions of Android. Only it’s called the “overflow menu”. So there’s no point checking whether there will be such a button or not—it will be there if it’s needed.

As a general guideline, you should check for specific functionality, not look at system/API version numbers. Use the ActionBar class if it’s available, otherwise fallback to the 2.x options menu.

Have you looked at Google’s action-bar tutorial? That makes it clearer what you should be doing.

Lawrence D'Oliveiro
  • 2,768
  • 1
  • 15
  • 13
  • 3
    Forgot to mention this: Of course I tried the legacy mode first, but in this case, listview performance is really terrible because of missing hardware acceleration. And as soon as you set tagetSDK to 14, you will have hardware acceleration again, but not the overflow menu. That's the reason why I display a menu button directly in the UI, but I would like to hide it if the device has a hardware menu button. – NiThDi Jan 29 '12 at 11:51
  • If the system has an ActionBar class, then the menu/“overflow” button is only shown if your app is ActionBar-unaware (which would be false in your case). So instead of checking where there is such a button, check whether the ActionBar class is available. – Lawrence D'Oliveiro Feb 01 '12 at 03:19
  • 4
    @ Lawrence D'Oliveiro: This is not entirely correct. If the theme is set to fullscreen, the actionbar is not displayed on ANY device in ANY Android version. That means on devices with no hardware menu button the options menu/ actionbar/overflow will not be accessible. Setting the theme to fullscreen will display activities on all devices like they are pre-honeycomb. The same is true for themes set to not display a titlebar, So, for apps running in fullscreen mode or notitlebar mode, checking for the hardware menu is necessary and, a fallback needs to be provided. – mrd May 25 '12 at 18:20
1

I think a possible and better solution is to add a own actionbar. So every device can see it and you don't have to check hardware configuration or Api version.

kinghomer
  • 3,021
  • 2
  • 33
  • 56
1

keysoft qualifier is used to detect a hardware keyboard not the navigation bar.

This article solves it:

Check for navigation bar

Darren B
  • 56
  • 2
-2

If you want a resource qualifier, which might be the case since you want to differentiate UIs, use keyssoft resource qualifier.

urSus
  • 12,492
  • 12
  • 69
  • 89