Android News
Honeycomb isn’t a phone OS, and maybe it never should be
February 1, 2011 | by Michael Heller
Android OS
A few days ago, once people had a bit of time to dig through the newly released Honeycomb SDK, it was found that there was a rudimentary smartphone emulator built in when you crank the resolution down. The tech world was suddenly buzzing with the idea that Honeycomb would be coming to smartphones after all, and the OS wasn’t “built entirely for tablets” as Google had claimed. Let’s slow down a minute, because I’m not sure there’s really any reason to believe that Honeycomb will make its way to phones; and, more importantly, I’m not sure it should.
In the in-depth talks on Honeycomb from Andy Rubin and Matias Duarte, both men have been very careful not to say that Honeycomb would also run on phones. Matias Duarte said, “What you see in Honeycomb is absolutely the direction for Android.” But, he never said that Honeycomb would be running on every device. He was saying that there were certain design elements that would become ubiquitous in Android OS iterations, like the software buttons, the multitasking UI, and the context sensitive action bar. When Andy Rubin previewed Honeycomb at the D: Dive into Mobile conference, he also never said Honeycomb would be on smartphones. Andy only stressed the fact that apps would work across devices, regardless of the OS version.
Fragments will ease fragmentation fears
Most people seem to have forgotten the “fragments” system that Andy Rubin mentioned when he first showed off Honeycomb on the Xoom tablet. Fragments are Google’s way of making development easier by allowing devs to simultaneously create an app that will run on both a smartphone and a tablet. The idea is very similar to what we’ve seen in the Eden paneling system introduced by Notion Ink. With this system, devs can make separate “fragments” within an app which would be shown side-by-side on a tablet, but would be separate pages on a phone. For example, in a mail app on a tablet, you could have the folder/message list in one fragment and the viewed message in another displayed side-by-side on the screen, but on a phone you would only see one at a time.
Given that Honeycomb is touted as being “built entirely for tablets”, this seems like a much more logical reason for why there is a buggy and simple phone resolution emulator in the Honeycomb SDK. Keep in mind that the UI seen in the SDK is also missing many of the new styling changes that have been built into Gingerbread, let alone any Honeycomb UI elements. Google knows that the world of tablets and phones need to be connected, but that doesn’t mean that the OS you use on each device needs to be the same.
Tablets are a new interaction metaphor
The fundamental way that people will interact with a tablet is different from a phone. Andy said himself, “It’s fundamentally changing the model of computing interaction. It is much more physical. You touch it. You feel it.” What you need and want to do will be different, and how the apps behave will be different, but that doesn’t mean that the apps can’t still be ubiquitous. The use case is inherently different. A tablet is much more of a couch/commuter device, where phones are truly mobile and are much more likely to be with you at all times. Consider iOS on the iPhone vs the iPad – what’s the difference? Not much. It’s the same grid of icons, the differences only arise once you’re in the apps. The iPad is also a consumption device at heart. Google may not want that. Given the options for alternative keyboards and voice input, the potential for Android tablets to be viable content creation devices is more apparent than with the iPad. The power and versatility of Android combined with the screen real estate available in the coming group of tablets are going to change how apps and widgets function, and how you interact with them. Those uses won’t always translate to the smartphone.
Honestly, I don’t know if Google plans to have Honeycomb eventually make its way back to phones. In fact, I’m not sure Google knows the answer to that yet. I think they want to create the best tablet experience they can, then, as always, leave it in the hands of users and developers for a little bit. See how it evolves, see how people use it, or want to use it. Then, make the decision from there. As long as developers can easily make apps that work on all devices, it shouldn’t really matter whether we use the exact same OS on every device, and it may not even be a good idea. Windows 7 will not make a good experience on a tablet. iOS would be terrible on a laptop. So, why should the OS have to be the same on phones and tablets? Because that’s how Apple is doing it? No. Apple can get away with that because of the simplicity of their OS. But, Android can be different, and make the OS fit the use of the device. I don’t want my tablet to be an oversized phone, so the OS shouldn’t be the same on both devices. Let Ice Cream Sandwich bring Honeycomb features to phones, but don’t force Honeycomb to be everything.














Great article, and some really good insight about what direction(s) Android is taking. That Honeycomb can stay tablet only and Ice Cream Sandwich should bring some of its features and APIs back to phones is an excellent point. This is why I like Androinica. You guys have some of the most intelligent and non-fanboy articles out there.
I just hope App development using the Android SDK will facilitate having a single project which target both the phone and tablet. Creating and maintaining two different layouts is simpler then creating and maintaining two different projects.
that is the aim of fragments. as per the Honeycomb SDK: "Because they are modular, Fragments also offer an efficient way for developers to write applications that can run properly on both larger screen as well as smaller screen devices."
As a developer the main thing I care for is the concept of "build once run everywhere". If the fragments enable the phone/tablet cross-development, God bless Google. Realistically it's the platform version that matters. Honeycomb will technically be API level 10 so if you build an app that uses the all-new and cool features of Android 3.0 it won't work on any existing phone, fragments or not. Potentially it'll work on the phones equipped with Ice Cream Sandwich (API level 11), which will presumably be more or less compatible with Honeycomb and will hit the market some day next year… If you are a developer you can't miss all the wonderful features of Honeycomb. You are left with the only option of building and maintaining two versions of your application: one for the phones and the other one for the tablets. Borys Burnayev actioncomplete.com GTD for Android and Web My recent post AC for Web Pro 2- Installment 2- Export to Printer-friendly HTML- Summary and Detail Reports
Isn't the rumor that Ice Cream Sandwich is being released this summer?
"The fundamental way that people will interact with a tablet is different from a phone." Actually, no. It's pretty much identical to how I interact with my Nexus One – i.e., via a touchscreen. Andy's comments are being taken too literally and out of context, just like the comments that made people think Honeycomb would need a dual-core processor and a 7" screen (see how well that story went, bloggers?). So many commentators seem wrapped up in "Honeycomb is a tablet platform" vs "Honeycomb is/isn't a smartphone platform". Get real guys, Android is a device platform. Google TV, Tablet, Phone, car, washing machine, whatever – it's a single OS. Google have no reason (technical or otherwise) to fork it into separate versions that would then become a maintenance and developer nightmare.
Having a single OS for both (all) platforms is simple, obvious and is the only solution (cf: iOS). It's also the only sensible path, and is the raison d'etre of Android. You people who constantly fret over whether Honeycomb might or might not come to Smartphones are clearly misunderstanding the entire fundamental concept of Android – that it's a hardware-agnostic platform. Do you see a forked version of Android for devices with/without gyroscopes/touchscreens/GPS or any other hardware? No. Proper app manifests and solutions like Fragments mean that it's not necessary. You think the claims about fragmentation are bad now? Imagine if there was "Android for Tablets" and "Android for Phones". That would be an utter utter fail – so much so that it's patently obvious that it's not going to happen. Honeycombe *is* Android.
The Motorola Atrix with the detachable keyboard/screen accessory shows that your phone and your tablet (or smartbook) is one device. How could your dual core phone NOT run Honeycomb? Clearly within the next year, a 10" touch screen will just be an accessory for your smartphone. Why would you buy a dedicated tablet device? A "tablet" is really just a dumb screen with a smartphone dock.
Don't cross led Zeppelin with android. Makes no sense Micheal. Not that u read the comments. Anyways, didn't martious or w/e say to engadget he doesn't understand why people don't think honeycomb is not also a phone OS. And either way, honeycomb is the way android is going. So build me my stairway to honeycomb.
Vindication! http://androinica.com/2011/02/03/google-says-hone… By the way, my name is spelled "Michael". No one on earth spells it "Micheal"
Agreed, Honeycomb should split off to its own Tablet only UI. Perhaps at some point down the line like "Ice creme" Google may incorporate some aspects of Honeycomb in mobile handsets. But this would be a nice point to break the two paths apart, for now until the Android Tablet get a nice foot hold in the market. As it will from what I see.