Also, one of Chrome's most touted features is performance, which has always been Android's weakest point. Hopefully he'll be willing to assign more people to the task of making Androids work as smoothly as iPhones.
This is not an impossible problem to mostly-solve, but it is orders of magnitude harder than what Chrome browser has to deal with.
Doing hardware integration is a lot harder than writing an app. I wish more app developers recognized this.
(That said: I do think Google could have done a much better job at separating out the true kernel/HAL/BSP layer stuff, which needs to be done per-device, from the framework layers that are largely device-independent. There's no reason to force a full hardware test just to push an fix for the Intents framework or whatever).
The reason for the hold out is the carriers, not Google. Google is very good at pushing updates to phones when it's not limited by the carriers (and Android implemented over the air updates years before anyone else did. iPhones still require cables to be updated).
For a Google SVP, much of the role is external. If getting partners on board is important and it hasn't happened, then you're out.
> The reason for the hold out is the carriers, not
> Google. Google is very good at pushing updates to
> phones when it's not limited by the carriers
Apple has managed to strong-arm the carriers into letting it supports its customers, and Google's market position isn't too much weaker than Apple.
> iPhones still require cables to be updated).
Google's customers get updates just fine.
Only for power and it's just a recommendation...
This simply isn't true.
Android is a Linux distribution, so most updates ought to be possible without having to reboot the device.
It's pretty much the equivalent of forcing a reboot of an OS like Android.