The Google Phone could be a ploy to upset the wireless industry, or it could be an expensive niche device. Either way, it is a bid to take Android back from the companies that seem hell-bent on destroying it.
Android's most serious problem right now is fragmentation: with each new phone, it seems, comes a different version of the OS. In theory, these differences are superficial, and come down to handset manufacturers' and carriers' custom interfaces, which sit atop a mostly unchanged Android core. In practice, it's much worse.
Just look at the current top tier of Android devices. The Motorola Droid runs Android 2.0. The HTC MyTouch 3G and G1 on T-Mobile run Android 1.6. The HTC Hero, a newer phone than the MyTouch and the G1, is still stuck on 1.5, along with the even newer Motorola Cliq, which shares one parent—Motorola—with the 2.0-loaded Droid. Why is this something to worry about? Remember Google Maps Navigation, the free turn-by-turn app for Android? It only works on Android 2.0 and 1.6. An app written by Google doesn't even work on every new Google phone. Imagine how things are with third party apps. (Spoiler: it's a $#@!show.)
Google's been fairly diligent about updating the free, open-source heart of Android moving forward at a steady pace, and supplying handset manufacturers with the tools they need to keep their handsets running the latest software. That said, Google still deserves some of the blame here. That their software updates include new, exclusive functionality is fine on its own. And yeah, their eagerness to allow for Android to be skinned and deeply customized by handset manufacturers is fine on its own—in fact, it's implicit in the project's open source ethos. But mixed together, these ambitions create a gurgling software slurry of incompatibility, user experience inconsistency and general frustration. (See: Samsung Behold II) So what happened?
The problem is in the model. Android updates seed out through carriers, over the air or with special installers. This is because the updates are their responsibility: once handset manufacturers (and carriers, through handset manufacturers) have built their own version of Android, they've effectively taken it out of the development stream. Updating is it their responsibility, which they have to choose to uphold. Or not! Who cares? The phones are already sold. And there's very little to motivate a carrier to update their Android phones, because the consequences of not doing tend to fall on Google: If Android fragments, the App Market doesn't work. The public sours. Android starts to suck. This is where the Nexus One comes in.
Sold without a carrier, software updates for the Nexus One will be in Google's hands. They will be able to keep it up to date as Android develops, without having to depend on some other company—or companies—not to drop the ball. This approach to software updates already has a case study: the iPhone. There's a good reason Apple didn't entrust AT&T with keeping the iPhone up to date, and that they didn't want the company that actually manufacturers the phone—Foxconn—to have any responsibility for its software. Smartphone software is finicky and complicated, and so is the experience of using it. It needs to be tightly controlled to remain consistent, and because apps are the most important part of a smartphone platform nowadays, consistency is life or death.
Without totally changing what the Android project is, Google can't put an absolute stop to fragmentation. What they can do is provide an example of how an Android phone should be done. With the Nexus One, Google isn't getting into the business of making hardware; they're just trying, in their passive, Googly way, to regain control of a project that's spiraling toward chaos.


</img>
</img>
</img> </img> </img> </img>


More...