Google cuts features out of Android OS

Google said Monday that it will cut two key features out of its upcoming "Android" mobile-phone OS: a formal Bluetooth implementation, and Google Talk, the developer’s version of instant messaging. However, Google said that the first phones will indeed have support for Bluetooth hands-free devices. On the other hand, HTC or T-Mobile, both carriers that have committed to developing Android phones, will apparently not have access to the API that exposes Bluetooth functionality; dedicated Bluetooth functions will apparently have to be designed in by Google itself.

Google’s omissions were noted as the company released a 0.9 beta to developers. On Monday, developer advocate Dan Morill explained the decision in a blog post. "Earlier this week, we released a beta of the Android SDK," Morill wrote. "In the accompanying post, I mentioned that we had to remove some APIs from the platform for Android 1.0, and as a result they don’t appear in the 0.9 beta SDK, and won’t appear in 1.0-compatible SDKs."

The Bluetooth API and the Google Talk functionality were the only omissions that Morill explicitly noted.

Morill quoted Rich Cannings, a Google security researcher, in citing the security concerns that Google had in adding the Google Talk functionality.

Cannings cited three problems with including Google Talk: the exposure of otherwise private information to the Web at large, issues with "Intent" messaging, and the lack of security technologies to prevent the widescale spread of a theoretical Android virus via Google Talk.

Google Talk is designed to allow users to identify themselves, including the disclosure of their actual names, to friends and contacts. But a large-scale, Android-based, multiplayer game using Google Talk would also expose this information to the game at large, a breach of privacy that users may not like, Cannings said.

Google Talk also does not include key security provisions to monitor "intents," or messages sent within the Android device.

"At first, remote applications could send arbitrary Intents, meaning that your Google Talk friends had almost the same control of your device as you did," Cannings wrote. "Even once that issue was resolved, we recognized that we could not trust the identity of the application who sent the request. We could only trust the identity of the user. So a "bad" application on your friend’s device could send a message to a "good" application on your device which would negatively affect the good application."

Finally, Cannings said that a lack of adequate security mechanisms within the Google Talk protocol itself would place too heavy a burden on developers: "An Android application using GTalkService would be reachable from all of the user’s Google Talk friends, and a flaw in that application could pose an inviting target to a malicious ‘friend’ or automated malware," he wrote.

Why was Bluetooth excluded? According to Android engineer Nick Pelly, "the reason is that we plain ran out of time," he wrote, as cited by Morill. "The Android Bluetooth API was pretty far along, but needs some clean-up before we can commit to it for the SDK. Keep in mind that putting it in the 1.0 SDK would have locked us into that API for years to come."

Morill said that the Android team remains committed to supporting a full Bluetooth stack in a future release, but when remains an open question. Proposed features include bindings to GAP and SDP functionality, access to RFCOMM and SCO sockets, possibly L2CAP socket support from Java, and an API for the handsfree and headset profiles.

"I’m definitely bummed about these API removals," Morill concluded. "I was particularly looking forward to the P2P capabilities offered by GTalkService, but, as always, user security and privacy must come first."

via stevetrotto.com and yahoo