Given the same base OS (Linux) in Android and ChromeOS and much of the same sorts of things. The redundancy of having two teams is pretty obvious. So if everyone agrees that you're going to do both going forward (and I think this is a ringing endorsement of ChromeOS as a 'long term' bet by Google) it only makes sense to make one team out of them.
Then the question becomes who leads it? The guy who leads ChromeOS or the guy who leads Android? Andy wasn't a big fan of ChromeOS when I was there, I don't know if that changed, his passion was making a better phone experience. I don't think I ever talked to or hear Sundar speak when I was there so I don't know what he thinks about phones.
So Sundar gets the nod and Andy gets to pick his next role (or exit which isn't uncommon in these situations). I don't doubt Andy would be on the short list of a number of CEO search committees so perhaps he'll pop up as the new CEO of Sony or something.
I would imagine it could start by eliminating bionic, which seeems designed primarily to keep hardware OEMs happy that everything is under a weak (BSD style) license.
ChromiumOS uses a standard Linux libc (probably glibc) and is more compatible with commonly available userland software and the newest ARM hardware and ABIs.
The Chromium build system is also more suited to building an OS than a Java application.
I'll assume that Dalvik stays, and that the Android API is supported.
The Android window manager is pretty powerful (actually underutilized on phone form factors, as it supports movable frames and overlap, though that is not apparent from using it. Chrome has it's own window manager, as well as it's own desktop UI.
One question might be what direction Google TV goes in, possible with a more exclusive partner arangement. Does it make sense to build Google TV apps on Android, or should it move to more of a web model using Chrome? (This isn't neccessarily assuming that Google TV survives as it's own product line).
I haven't seen what information has been publically released about Google Glass development, but it's UI could be accomplished equally with Android or Chrome underneath, and eventually it makes sense for them to be webapps.
Another possibility, seemingly out there, would be for Android to move towards a WebOS/FirefoxOS model where core applications are built using HTML and interfacing with exposed libraries, but Android apps would still be first class citizens.
I think this may sound crazy but android's days as a apremium OS are not as secure as they seem. Take Samsung out of the android picture and you will see that there is barely any device maker that is leading charge.
Add to that the pressure brought on by Microsoft which runs almost the same version of OS on its phone and PC. This will allow them to innovate much faster. Google wants to be there. So even though the brand name will stay, Android as n OS will evolve to what is Chrome today. Completely controlled by Google.
I'll take that bet. Instead I think it's going to happen the other way. Chrome is going to be more tightly integrated into Android. Eventually the Play store will contain Chrome Packaged Apps that appear to the user no different than the Java apps. Chromebooks will remain untainted. They'd be giving up too much security wise by allowing native apps on Chrome OS, one of its biggest selling points.
ChromeOS is going nowhere, it's currently the best OS option that is able to turn a PC into an instant-start, always-connected "appliance" where end-users don't need to care about the mundane details of using a PC, e.g managing files and folders, backing up, syncing, updates, security and virus-scanning protection, etc - everything runs in a sandbox, gets updated automatically and "just works".
I think there's no point in carrying forward ChromeOS ahead, when Android can already do so much more, without needing to be always connected to the internet. The world (even the first world) hasn't reached to a place yet where it can depend on always being connected.
How is ChomeOS better positioned for this metric than iOS or Android? While I am not a huge fan of them as general purpose computers, our Kindle Fires actually fit these bills rather well.
Except it doesn't "just work". For example, offline support is abysmal, and standard tasks such as viewing PDFs or Office documents are riddled with display bugs. Chrome OS has a long way to go before it's a serious competitor to the mainstream operating systems.
Yeah it's just a browser if you forget about the Custom Firmware, Custom Hardened Linux OS with auto-updating sandbox, built-in TPM support and a trusted bootpath optimized for FastBoots, customized Portage build system, Custom Window Manager, built-in media player, file manager, integration with Google Cloud Print, Chrome Shell/SSH, Chrome Remote Desktop.
But it's comforting that there are people that just think of it as just another web browser - that's the whole point, just think of it as a web browsing appliance that "just works like a browser" -- even though it's not.
Chrome is a platform for running web apps, just like android is a platform for running android apps. It is literally the exact same concept, each type of app just has different strengths and weaknesses.
I believe Chrome will exist as a unifying brand. ChromeOS will probably be web apps running alongside a "native" Android apps on an Android foundation. Over the last year, Google has been downplaying the Android brand and differentiating its own Google-branded devices.
How would that work? What would it be like? Android is powered by native apps, Chrome by cloud apps. Chrome already runs on Android. They have different approaches and I don't see how they how they could form a coherent whole or how one would benefit from a merger with the other. :/
Move Native Client for ARM into Chrome on Android (or, wait until PNaCl is ready, and move that into Chrome for Android).
Focus effort on exposing functionality currently available to native Android apps through web APIs in Chrome to make Chrome apps (using NaCl/PNaCl where that kind of performance is needed), rather than Dalvik ones, the preferred mechanism for delivering apps on Android.
At that point, Android and ChromeOS are pretty much the same thing.
Thanks for your input. Now I can see how that would fuse the systems and how that would make for better web apps that had the strengths of native apps (Something like Firefox OS I figure).
But would that improve the Android platform? I'm wondering if it would be confusing or complicated for users, getting some apps from play and other from the Chrome store. Having apps in the launcher and some other apps you have to run from Chrome. Although at that point Google could merge the Chrome store and Google Play and have shortcuts for Chrome apps that launch a chrome-less browser to look native. Now that I've though about it I think it could work rather well, but I'm still wondering what would be the benefit for the users of Android.
Edit: Now that I've seen vibrunazo's comment I think I get it. If Google build a web programming api that is the same as Android's programming for one is programming for the other. I think that would be truly awesome indeed, I enjoy developing for android, not so much for web.
Good point. Android is ahead of Web apis, and Google have been adding android apis to the Web for a while (example intents). They just need to keep doing that until there's 1:1 feature parity, so we can develop apps for either one or the other as if they were the same. And the same apps would work predictably on both.
> Android is powered by native apps, Chrome by cloud apps.
Android is powered by Java apps (mostly). Java apps run in a virtual machine, just like web apps. Java apps are no more native than Chrome packaged apps.
No no, a cloud ecosystem, on an operating system, on top of an operating system, on top of the linux kernel. It's a great idea, especially on a power-constrained device like a phone.
Just add in Bellard's jslinux, and you can go 'round again.
That's very likely the intention here. If not merging them fully then at least synergies between similar areas of the two and a merging of the app ecosystem of each.