Honeycomb Won’t Require Physical or Capacitive Buttons



More and more info is coming to light about Honeycomb now that Andy Rubin’s full D: Dive Into Mobile interview is live. One piece of info emerging is that the Honeycomb Android OS update won’t require that a phone has physical or capacitive buttons. Instead, the Android Team has opted to move the traditional Home, Menu, and Back buttons directly into the UI of the interface. If we had to guess, that would be the three icons you see in the lower left corner of the tablet pictured above. Rubin explains the reason for this move is so that users will always have quick and easy access to the common OS commands regardless of screen orientation.

Of course, eliminating hardware buttons isn’t a requirement, and we are sure plenty of Android phones and tablets will continue to deploy some variation of the standard four Android buttons. Our biggest worry is that if and when Honeycomb makes it to smaller-screened devices that the software buttons will take up valuable UI space, eating away at the amount of information that can be displayed on a small display.

Google looks to be covering a full gamut   of UI changes in Honeycomb, just as promised. While initial peaks at leaked screen shots look promising, we’ll have to wait for a full reveal before passing any judgement.

[via PhoneDog]

Kevin Krause
Pretty soon you'll know a lot about Kevin because his biography will actually be filled in!

Notion Ink Adam Ship Date Slips Back, Doubt Continues Over Legitimacy

Previous article

Android Malware Attacks Up Significantly from Last Year

Next article

You may also like


  1. Please no! At least not for phones! Real buttons are so much better.

  2. Looks great. Hopefully the ugly designs of yesteryear will be bygones and devices will be competitions in how to make a screen and a case without a bezel look as good as possible.

  3. Good news is that it is an open OS, so you don’t have to include the software buttons for any device that already has buttons.

  4. Phones no, tablets yes. Should standardize on button configurations too, assuming the OEMs don’t screw that up as well. Wonder how launchers like ADW will handle this option.

  5. Definitely glad they don’t HAVE to have it. I’d much rather have more screen, even on a phone. I like physical buttons, but if you are going to have the buttons capacitive anyway, just extend the screen! And that way you have a choice for where to have them…

  6. The physical buttons is something that makes Android better than the iPhone.

    I think its a good idea for tablets but NOT for phones.

  7. I agree 100% with Steve. I play with an iPhone or iPad and get almost immediately aggravated with the poor navigation setup. The buttons are perfect as they are. Its fine for tablets but don’t waste phone screen space for this.

  8. I think this is a good thing. And it confirms to me that Honeycomb is aiming to be the “tablet” version of Android. Not that it CAN’T be used on a phone – that’s the OEM’s choice, of course. But Honeycomb is optimized for tablet use, and this little tweak only helps confirm this.

  9. I hope it will at least have a power button. :-)

  10. will make the button remapping software very useful and a must have.

  11. Here in Androidland, I thought we believed that choice was good. I like this move as long as the on-screen buttons can be disabled for devices with hardware buttons. As long as there are folks like us who want the hardware buttons, OEMs will continue to deliver them. Choice is good. Choice is good.

  12. why does it say January 23? Is that a reveal date?

  13. Tablets I can agree with but definitely not phones. I hope they add a way for developers to add buttons to it as there’s quite a few apps that have a bottom navigation bar – the new Phandroid app being 1 of them with the previous/next buttons on news items. Would be annoying having the Android buttons on a bar with app specific buttons on top and it would be nice to have a bit of standardisation for that kind of thing.

  14. The versions of Android (Eclair/Froyo) running on the new Archos tablets already are using this method of moving the 4 buttons to the UI.

    It is interesting that Google has seemed to pick up on this, at least for tablets. not sure how I feel about it on the phones yet.

  15. No big deal.

    Anyone who has an HTC Evo knows it wont be a big deal.

    No Worries here.

  16. @Juan

    Actually, Jan. 23rd lands on a Saturday in 2011.

    Maybe the time wasn’t adjusted. Or wasn’t connected to the internet.

    My opinion

  17. Alas, januari 23 2009 was on a friday. Was it ready by then?

  18. I hope they keep the hardware buttons. I don’t want to lose some of the screen.

  19. They could just make it so you can just perform a swipe up action to bring up the “buttons”. That would eliminate the screen loss.

  20. I don’t think you need to worry. Assuming this does make it to smaller devices, I’m sure Google has added switches into the OS to define whether the device has hardware buttons or not. This would be similar to differences between a phone that uses a physical keyboard, or an on-screen keyboard.

  21. I don’t understand why people are complaining about losing screen space because of the buttons. That means that there will be little or no need for actual buttons on the phone. So, take away my Evo’s buttons & ill have more room for screen. So ill have about a 4.5″ screen. But replace a small portion @ the bottom of the screen & add software UI buttons & then I’ll prolly have a 4.3″ screen again.

  22. I for one wont be wasting money on a phone or tablet with out the 4 standard buttons.

  23. iPhone owners who have been putting Android on their phones will love this because now they won’t have limited functionality because of its fail one button design.
    Android FTW

  24. Seriously? this was known over a week ago during Andy Rubin’s original interview and presentation of the Motorola prototype. You guys and Phone Dog are getting more pathetic about the stuff you write as time goes by.

  25. Please no! My nexus has buttons for a reason!!””

  26. Isn’t this old news?

  27. I’m surprised nobody has seen a potential benefit to this!

    The biggest fragmentation issue for android is PLACEMENT of the hardware buttons.

    So if the software can control the standard buttons on the buttom, shouldn’t a custom layout be possible?

    Just thinking out loud

  28. Remember that part of honeycomb will be code in the SDK to automatically detect whether an app is running on phone or tablet. Give that, it’s no stretch to assume these soft buttons will behave the same way.

  29. The reason they went with software buttons instead of hardware is all because of how you hold it. With a tablet, you want to be able to shift your hands around and pass it around without touching any external buttons. It actually is pretty nice on the Archos, well, I mean if the Archos was powerful enough it would be nice.

    This tablet will have a 360 degree rotation, there is no right way to hold it…every way is the right way to hold it. What I’m curious about is if you can add Apps to that bar at the bottom..maybe something like Windows 7 with icons.

  30. HOORAY! Physical buttons annoy the hell out of me. They just don’t belong in a touchscreen world. Surely you can all see that. It feels so unnatural to play with the virtual buttons on the screen, and then at some point you HAVE TO use the physical buttons *click* and it’s like you feel disconnected for a while. Removal of the buttons will mean bigger screen on SAME phone sizes as we had so far – maybe we’ll have 4.5″ phones from now on as the optimal size. Virtual buttons also don’t have to stay fixed, so in some instances, like when browsing, watching a video or playing a gam you’ll be able to benefit from the whole 4.5″ screen. Time to accept that we’re living in a touchscreen world now, and physical buttons are a thing of the past. Stop being so conservative. It will only get better from now on, especially once we’ll have pressure sensitive and texture feeling touchscreens.

  31. I like the external buttons. They’re always in the same place, and they work the same way most of the time. I hate it when i borrow an iPhone, the tiny screen is made even tinier by having back and menu soft bottons covering up parts of pretty much every single app. The screen is where you keep content. not chrome.

    I do like the idea of there not being an up and down on honeycomb tablets. It’ll look cool with OLED screens, you won’t be able to tell where the screen turns to bezel, there’ll just be buttons following you around.

  32. @Lucian
    I suppose that might work although if screens did get bigger then phones would have to be wider to keep the aspect ratio the same.
    The only way it will work is a time delay or API hooks that an app can use (e.g. a movie player) to get rid of the buttons and tap the screen to bring them back up. Gesture based won’t work as an app might translate that gesture into another action and a physical button means an extra button press and where do you place it if the whole idea is to be able to use it in any orientation.
    Hardware buttons shouldn’t all be gotten rid of though, 1 of the reasons I got a Cowon S9 is because even though it’s a touchscreen I can use the hardware buttons to skip track, etc. without taking it out of my pocket.

  33. @Lucian
    No matter how much of a touchscreen world it may become.. there will always have to be one button… (POWER ON) ;)

  34. It wouldnt make sense for the soft buttons to occupy space on the already limited space available on a cellphone. It makes sense on tablet. This could be one area where Honeycomb implementation is different between cellphones and tablets (just like the same app shows up differently on cellphone and tablet)

  35. @Todd
    Good point…custom button layouts…

  36. At least make two versions of Honeycomb. One for small screen devices that will have hardware buttons(capacitive or physical). And then the large screen devices will get UI buttons and not hardware ones.

Leave a reply

Your email address will not be published. Required fields are marked *