Google To Hold Back 'Honeycomb' From Phones

[digitalnirvana 646]

Google will hold back its Android 3.0 "Honeycomb" to smaller phone manufacturers for an undisclosed period of time, Google said Thursday.

Google said that Honeycomb was designed for tablets, not phones, and that it had more work to do before Honeycomb was released in an open-source format, a Google spokesman said in an email.

The delay will probably be on the order of several months, Google told BusinessWeek.

"Android 3.0, Honeycomb, was designed from the ground up for devices with larger screen sizes and improves on Android favorites such as widgets, multi-tasking, browsing, notifications and customization," Google said in an email to PCMag.com. "While we're excited to offer these new features to Android tablets, we have more work to do before we can deliver them to other device types including phones. Until then, we've decided not to release Honeycomb to open source.We're committed to providing Android as an open platform across many device types and will publish the source as soon as it's ready."

That means that smaller phone manufacturers who wish to use Honeycomb will have to wait an undisclosed amount of time before they can get access to the code. But larger OEMs, such as HTC or Motorola, already have access to it. Those OEMs, however, are generally placing it inside of tablets, like Acer is doing.

However, that leaves carriers like Cricket Wireless, and its plans to carry forthcoming seven-inch Anydata tablet that will run on Honeycomb, up in the air.

Andy Rubin, vice-president for engineering at Google and head of its Android group, explained the delay to BusinessWeek.

"To make our schedule to ship the tablet, we made some design tradeoffs," Rubin told the magazine. "We didn't want to think about what it would take for the same software to run on phones."

Rubin also said that Google didn't want to risk "creating a really bad user experience".

In February, at Google's Honeycomb launch, a Google spokesman said that that Honeycomb is exclusively for tablets right now, and "features will arrive on phones over time." But the version of Android which includes those features on phones may not be called "Honeycomb," or may have a different version number than 3.0.

In February, Google announced that the full SDK for Android 3.0 is now available to developers.

"The APIs are final, and you can now develop apps targeting this new platform and publish them to Android Market," Xavier Ducrohet, Android SDK tech lead, wrote in a blog post.

While app developers get their crack at Honeycomb, OEMs apparently will be much more restricted. Will this reduce Android fragmentation? Time will tell.

Source: thinkdigit.com

[rajanmehta 4,056]

Not only phones, according to this article http://www.unwiredvi...upgrade-to-3-0/ if a hardware partner releases a tablet on Android 2.x version, as per licensing agreement for Android 3.0, they are not allowed to update Android 2.x tablets to 3.0 version.

There was also one more interesting quip about Android 3.0 in Eldar's article. According to him, if a hardware partner releases the tablet on Android 2.x version of OS, as per licensing agreement for Android 3.0, they are not allowed to update Android 2.x tablets to 3.0 version.

If that is true, current Samsung Galaxy Tab users are really out of luck here. And potential buyers of HTC Flyer, if and when it is released with Android 2.4 as demoed at MWC, should wait a few months until HTC comes out with Android 3.0 of their tablet.

The same article also mentions that Google is working with LG for Pure Google Honeycomb Tablet with an updated version of Honeycomb.

[digitalnirvana 646]

That would be extremely controversial because except the Xoom all existing tablets are on 2.x, surely there would be a backlash if this is implemented and it would harm 3.0 badly, surely customers would not buy new tablets just for new OS. Clearly remember Notion Ink saying the Adam which is 2.2+ would get 3.0, so need to see what Google does.

[rajanmehta 4,056]

Rumor: Google Plans On Tightening Its Grip On Android To Reduce Fragmentation And (Hopefully) Get Rid Of Unwanted Custom UIs

Android Police

For everything that we love about Android – openness, customization, large selection of devices, etc. – there are things that we hate about it, too, like fragmentation and manufacturers pre-loading devices with crapware and (some) custom UIs. It seems, though, that Google is looking to change all of that. Insiders from companies "in the Android ecosystem" have told Businessweek that Google is starting to crack down on changes that manufacturers are allowed to make to Android. This includes more than just interface tweaks and added "features", and it is said that Google wants to be more selective with hardware, as well.

The purpose of the (seemingly) sudden shift in Google's practice is to combat the most talked about flaw in Android – fragmentation. In the past, Google has worked with specific chipset and handset manufacturers to release pure Google Experience Devices for new versions of Android – the Nexus One (Qualcomm and HTC; Froyo), Nexus S (Samsung; Gingerbread), and most recently, the Xoom (Nvidia and Motorola; Honeycomb). Because of this, these devices have always been (or will be, in the case of the Xoom) the first to receive OS updates, while other manufacturers have to ensure that all of their custom software plays nicely with the new OS. This has left some waiting for months to receive updates to the newest versions of Android, while others were just left behind for good. By taking more of a "Nexus approach" in the future, Google will be able to reduce fragmentation, and manufactures will be able to release handsets quicker. Google has already started to display some of this behavior by holding the Honeycomb source code so it doesn't get ported to devices that aren't meant to run the tablet-specific OS.

Some manufacturers are not happy with Google's decision to take control of their own product, however. You see, before getting the okay to work on an Android project, manufacturers have to detail what they plan on doing and get approval directly from Andy Rubin. This creates an interesting situation for companies like Facebook who may be working with hardware manufacturers developing new features for Android devices, since giving up future plans to direct competitors is generally not the best business practice.

What does this mean for consumers, you ask? First and foremost, it means quicker turnaround times for OS updates. It means less confusion and hopefully more Google Experience devices. I say that we, as a whole, embrace this new direction for Android. We're all going down the same path, and now we will be able to go at the same pace.

Original Source Articles: Businessweek http://www.businessw...23041200216.htm Electronista http://www.electroni....android.3.arm/

[digitalnirvana 646]

This was bound to happen, Big G has finally started curbing the openness of Android, and definitley many opensource proponents/devs/modders will be angry but - if Google can pull this off it will damage iOS and Apple massively - because Steve Jobs always used to criticize Android's fragmented user experience compared to iPhone's "

one model, one experience" - if Google can find balance between open source and consistent user experience then Android will be winner.

[Karthik R 246]

Alarming to see google shifting away from its open-source, open-handed approach to Android..

This narrows down the pros of android os over Apple's ios

[drmadhu 87]

This is very bad news

[rajanmehta 4,056]

Android chief Andy Rubin tackles open source qualms, says Honeycomb isn't 'one size fits all'

Andy Rubin. Android Developers Blog

Recently, there's been a lot of misinformation in the press about Android and Google's role in supporting the ecosystem. I'm writing in the spirit of transparency and in an attempt to set the record straight. The Android community has grown tremendously since the launch of the first Android device in October 2008, but throughout we've remained committed to fostering the development of an open platform for the mobile industry and beyond.

We don't believe in a "one size fits all" solution. The Android platform has already spurred the development of hundreds of different types of devices – many of which were not originally contemplated when the platform was first created. What amazes me is that the even though the quantity and breadth of Android products being built has grown tremendously, it's clear that quality and consistency continue to be top priorities. Miraculously, we are seeing the platform take on new use cases, features and form factors as it's being introduced in new categories and regions while still remaining consistent and compatible for third party applications.

As always, device makers are free to modify Android to customize any range of features for Android devices. This enables device makers to support the unique and differentiating functionality of their products. If someone wishes to market a device as Android-compatible or include Google applications on the device, we do require the device to conform with some basic compatibility requirements. (After all, it would not be realistic to expect Google applications – or any applications for that matter – to operate flawlessly across incompatible devices). Our "anti-fragmentation" program has been in place since Android 1.0 and remains a priority for us to provide a great user experience for consumers and a consistent platform for developers. In fact, all of the founding members of the Open Handset Alliance agreed not to fragment Android when we first announced it in 2007. Our approach remains unchanged: there are no lock-downs or restrictions against customizing UIs. There are not, and never have been, any efforts to standardize the platform on any single chipset architecture.

Finally, we continue to be an open source platform and will continue releasing source code when it is ready. As I write this the Android team is still hard at work to bring all the new Honeycomb features to phones. As soon as this work is completed, we'll publish the code. This temporary delay does not represent a change in strategy. We remain firmly committed to providing Android as an open source platform across many device types.

The volume and variety of Android devices in the market continues to exceed even our most optimistic expectations. We will continue to work toward an open and healthy ecosystem because we truly believe this is best for the industry and best for consumers.

[KanagaDeepan 1,084]

Good...

[rajanmehta 4,056]

Editorial: Android's problem isn't fragmentation, it's contamination

Vlad Savov. Engadget

This thought was first given voice by Myriam Joire on last night's Mobile Podcast, and the simple, lethal accuracy of it has haunted me ever since. All the hubbub and unrest about whether Google is trying to lock Android down or not has failed to address whether Google should be trying to control the OS, and if so, what the (valid) reasons for that may be. Herein, I present only one, but it's arguably big enough to make all the dissidence about open source idealism and promises unkept fade into insignificance.

Let's start off by setting out what the goal behind Android is. It'd be impossible to identify the flaw with Google's strategy if we aren't clear on what it's strategizing toward. From its very inception, Android has been about expanding the reach of Google search. Never mind all the geeky professions of wanting to build a great mobile operating system and one which Googlites themselves would want and be proud to use -- there's no reason to doubt the veracity of those proclamations, but they're symptomatic, a sort of nice side benefit, of the overarching business decision. Google makes its money by selling ads. It sells those ads by serving them up in front of its vast audience, which in turn comes to it primarily through the use of Google search. When faced with the rampant ascendancy of mobile internet use -- and Google deserves credit for identifying the oncoming smartphone craze in good time and reacting to it -- the company knew it simply had to maneuver its products into the mobile realm or face a slow, ignominious path to irrelevancy. Ergo, what Google was really and truly striving for with Android was ubiquity. Instead of having to dance to the merry tune of carriers -- as Microsoft is now having to do with Verizon in order to get it to bundle Bing on some Android devices -- or appease manufacturers' many whims, Google opted to build its own OS, with that specific aim of expanding availability as rapidly and as broadly as was possible.

To say that the goal has been accomplished would be an understatement. Android has stormed every Symbian castle, ransacked every webOS village, threatened the mighty tower of Mordor iOS, and thoroughly resisted the upstart challenge of Windows Phone 7. The reasons for its success and universal acceptance have been twofold. Google has invested plentiful resources into expeditiously building up its Linux derivative for the mobile space, on the one hand, and has decided to make the fruit of that labor available to phone manufacturers without hindrance or demand -- to use as they pleased, for it was open and flexible, and while it wasn't initially beautiful to look at, it was a sturdy platform from which to build.

Many have characterized the resulting melange of multivariate Android skins and devices as generating fragmentation within the OS' ecosystem. That may be true, but is not in itself problematic. If there were no qualitative difference between Android on an HTC device and Android on a Sony Ericsson phone, the end user wouldn't care. He'd call that choice.

Where the trouble arises is in the fact that not all Androids are born equal. The quality of user experience on Android fluctuates wildly from device to device, sometimes even within a single phone manufacturer's product portfolio, resulting in a frustratingly inconsistent landscape for the willing consumer. The Sony Ericsson Xperia X10 is a loud and proud Android phone, but it features an older version of the OS, has had a checkered history with updates, and generally leaves users sore they ever picked it up. At the same time, Samsung's 10 million unit-selling Galaxy S is too an Android phone, one that Google can rightly be proud of. The most irksome example, however, is LG's Optimus 2X -- it has Froyo on board both in its European 2X garb and in its US-bound G2x variety, but the former crashes the browser any time you look at it, while the latter, eschewing LG's customizations and running the stock Android 2.2, is one of the slickest and smoothest devices we've handled yet.

The point is not that carrier or manufacturer customizations should be abandoned entirely (we know how much those guys hate standardization), it's that some of them are so poor that they actually detract from the Android experience. Going forward, it's entirely in Google's best interest to nix the pernicious effects of these contaminant devices and software builds. The average smartphone buyer is, ironically enough, quickly becoming a less savvy and geeky individual and he (or she) is not going to tolerate an inconsistent delivery on the promise contained in the word "Android."

It may seem odd for us to pick faults with an operating system in the midst of a world-conquering tour, but then you only need to look at Symbian's fate to know that fortunes change quickly in the breathlessly developing smartphone realm. All Google really needs to do to patch the cracks and steady its ship is to live up to those rumors of Andy Rubin ruling from above. Dump the X10s and 2Xs from the portfolio of real Android devices -- and Google can do that by denying them access to its non-open source products like Gmail, Maps, and the all-important Android Market -- and give us some respite from having to worry if the next Android will be a rampant robot or a dithering dud. Custom skins can still live on, but it's high time Google lived up to its responsibility of ensuring they're up to scratch before associating its mobile brand with their final product. Such a move may dent the company's valuable reputation as a do-gooder, but if it helps the even more valuable Android OS keep its course toward world domination, surely it'd qualify to be called a good thing in and of itself?

[digitalnirvana 646]

Very interesting read and would partially agree, while the post throws up very valid pointers, I still think that approach of an OS manufacturer clamping down on the openness and especially imposing hardware conditions on OEMs is outright failure at worst, and hit and miss at best.

Let us take two examples, both dealing with the behemoth we love to hate - Microsoft.

Case 1 - Windows Phone 7 did the exact same thing that Android is trying to do by standardizing and dictating the specifications of hardware OEMs. E.g. all phones had to have minimum specifications, had to have specifically mapped Windows button, etc. You can read more on the internet but basically what WP7 tried to do was to achieve uniformity (by specifying mapped keys layout, discouraging skins/shells) and consistent user experience. WP7 did achieve this, but sales wise it has disappointed. Verdict - hit and miss success.

Case 2 - Windows Vista did not have reverse compatibility (even though it has compatibility mode but most existing software had problems running on Vista) for existing/older programs and demanded outrageously high hardware capability from OEMs. The reason given was that this level of hardware was needed to experience the benefits of the OS to optimum level. This approach meant a> most home PCs did not migrate to Vista because the hardware criteria was not met and b> most businesses did not migrate to Vista because the programs they wanted to run were often not possible on Vista due to it's lack of reverse compatibility. Verdict - flop.

Now look at the current Android landscape. A G1 which is the oldest pure Google phone gets Gingerbread, yet a Hero which is a year newer, does not get Froyo officially. Openness? Double standards, more like! Carriers will always try to not support moderately old sets to push sales of new products. But the Google approach of opensource has allowed devs/geeks to put any version of Android (stock AOSP, not skin like Sense) on any phone. Of course, some hardware limitation would be there like Flash not running on ARMV6 processor, but the bottom line is, users have been able to enjoy latest Android OS on their mobiles by virtue of the opensource community, irrespective of their phone's hardware capability.

Now think about Google's approach of curbing openness in the name of reducing fragmentation. Imagine you had spent 200$ on an Epic for a two year contract and 1 year into it, you found your phone is obsolete and would never get any more updates. What would you prefer? An official outdated OS "supported" by Sprint, or a community built/Google provided stock version of latest Android? I know which I would want.

Android must not impose hardware limitations on OEMs and definitely must not "Dump the X10s and 2Xs from the portfolio of real Android devices -- and Google can do that by denying them access to its non-open source products like Gmail, Maps, and the all-important Android Market". That would spell death for the platform.

Remember, Facebook is waiting in the wings. They have already developed INQ cobranded phone, and they have the advantage of having captive user base of 600 million.

Android must find ways to reduce fragmentation, but not at the cost of denying older sets a taste of latest OS.

Edited April 10, 2011 by dipanlahiri

[sougatadc 358]

Google mulling tablet version of Chrome OS

Despite launching the Android Honeycomb Operating system recently, Google is now planning to bring the tablet version of Chrome OS, according to CNET.

The source code has been discovered from the Cr-48 laptops distributed by Google itself to test its Chrome operating system for netbooks. At several places, the source code mentions CrOSTouch instead of CrOS.

The code also mentions the presence of a virtual keyboard which cannot be of much use on laptop, but an essential on the tablets.

The news has surfaced at a time when everyone thought that Google was concentrating more on Android, and more specifically, Honeycomb.

The new tab page of Chrome web browser, CNET says is one of the signs that Google is working on the new OS.

Google is probably preparing for a future in which the netbooks and tablets will have a unified interface, and the Google users would have a consistent experience across both the devices.

While some market observers opine that the two projects will combine in the future, others believe that Android will end up destroying Chrome.

The Google observers should be the least surprised, given that Google had shown off the mock up of Chrome on a tablet about a year ago itself.

Source: the mobile indian

[digitalnirvana 646]

Chrome is Google's proprietary OS closed source targeted at cloud, Android is open source targeted at mobile ecosystem. For notebooks/tabs Chrome would be pushed while for mobiles Android in the interim. Eventually Chrome would be primed to take over Android in my opinion, however if you go through the below article, bit long but good read, and go to the comments given on that website, opinions are divided. Though this is bit off topic, but since you raised this pertinent point, no harm in discussing here.

Android vs. Chrome OS: One broad idea with two futures?

With the recent statements from Google on the future release of the Chrome OS on tablets in the future, there has been many a healthy debate on the future of the two projects. The Chrome OS vs. Android discussion has been going on for quite some time but with tablets it will be the first time they actually share markets. While certainly very different in their approaches, the two will be competition in the tablet market which seems to grow with each passing day. The question is, is the competition healthy?

First off, it’s important to note the differences between the two.

• Android is a native OS, meaning it’s apps and information is stored on the user machine while Chrome OS is entirely web based.
  
• Android is primarily used on mobile devices while Chrome OS is specifically targeted to netbooks and, likely, tablets.
  
• Chrome OS will require internet access while Android works with sporadic access
  

Next, it’s important to discuss some of the history of the two projects. Android started and to this day remains a primarily mobile operating system, for phones and PDAs, etc. Nevertheless, it is growing in the tablet field with the most notable product being the Motorola Xoom. Chrome OS is still in the early stages overall, with a release date fast approaching and the tablet mechanics obviously just getting started.

So what does the future hold? Well, to be completely honest, I think the two will coexist. There’s been debate over combining the two together into one project, which in programming terms would actually mean to build what the other does from the ground up, but I think there’s subtle but important differences that will lead them into different futures. I love my Android phone and would definitely be interested in a tablet, but at the same time I think I’d prefer a tablet with Chrome OS on it. Why? Because when I’m mobile I expect my machine to be fast. This isn’t a dig at the Android by any means, but when I’ve had my notebook and been travelling, typically what I encounter is a sort of leapfrog: queue up a task, move, work on task, move, queue up next task, etc. With Chrome OS, the real work is being done on servers and machines far more powerful than mine that can pull in the resources desired in a moment’s notice. All the local machine has to do is portray via the monitor and UI what is going on. That, to me, sounds excellent. I’m a huge fan of cloud computing and as a PC gaming enthusiast, have watched as the movement has grown tremendously over the past few years. With the ability to work or browse on the fly in real-time, that to me sounds excellent.

You may be thinking to yourself though, ‘You idiot, your hardware must ****,’ and that is certainly part of the case. I’m a budget spender, but more importantly software continues to grow in it’s memory usage rate each year. How does this affect your Chrome OS machine? Hardly at all. Since the actual work takes place ‘off-shore’ the machines that run them must of course be updated while we users get the benefit of things simply just working. The Android doesn’t have this same ability since the work takes place on the user machine. And they’re both great.

I love technology dearly, I’m a fan of watching things grow year-in, year-out and hardware is definitely a part of that. There are some things that are just better when run on your own machine, but at the same time a world where things work at the speed of thought is fantastic as well. Chrome OS hands-down offers the greatest speeds of the two, which in today’s world matters greatly.

Speaking of today’s world, there is one area where the two differ greatly. I’m from a rural area so constant internet connectivity means having a card from my local phone service connecting me to the internet and even then it’s spotty at best. Chrome OS requires continuous internet access to work and, while we’re still very early in the process, the ability to connect via anything besides a land line or WiFi hasn’t been mentioned. That’s not to say it isn’t in the works but Android has this ability built-in. In larger cities, campuses, or businesses where it’s not an issue Chrome OS will definitely shine and as we progress forwards, more of the country will be covered in WiFi hot spots and such but it’s definitely a chink in the armor for now.

I genuinely believe though that there is room for both systems and wouldn’t be at all surprised if they stayed as separate projects. Some people may say it’s stupid to have both, but they play to different crowds and that’s definitely a good thing. Google has the opportunity to please the extreme-mobile, extreme-modder, and casual crowd with both systems should they play their cards right. While splitting up a market with internal competition is widely regarded as a bad move in the business world, I think with the right approach Google can play to their strengths of the individual OSs. I for one like having the options.