Last week, Google offered up a new version of the Android SDK. The new version added a lot of great stuff, but also subtracted support for a few elements. Those elements were Bluetooth and GChat. Google felt the need to explain itself. Here's what it had to say.
The Android Developers Blog was updated last night with some more information about the status of the Android 0.9 and 1.0 SDKs and the differences between the two. Many developers were excited about many of the fixes made to the code, but there also was disappointment. The Bluetooth and GChat APIs had been removed from the SDK.
Android will support Bluetooth headsets, but right now, the API isn't available for third-party developers to take advantage of and incorporate into their own applications. Google says there is a good reason:
The reason is that we plain ran out of time. 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. Here's an example of the problems in the API. Client code is required to pass around IBluetoothDeviceCallback objects in order to receive asynchronous callbacks, but IBluetoothDeviceCallback is meant to be an internal interface. That client code would break the moment we added new callbacks to IBluetoothDeviceCallback.aidl. This is not a recipe for future-proof apps. To make things even more tricky, the recent introduction of the bluez 4.x series brings its own new API. The Android Bluetooth stack uses bluez for GAP and SDP so you'll see more than a passing resemblance to bluez's interfaces in Android. The bluez 4.x change requires us to carefully consider how to structure our API for the future. Again, remember that once we settle on an interface we need to support it for years going forward.
Although we would have loved to ship this service, in the end, the Android team decided to pull the API instead of exposing users to risk and breaking compatibility with a future, more secure version of the feature. We think it's obvious that this kind of functionality would be incredibly useful, and would open lots of new doors for developers. One of our top priorities after the first devices ship is to develop a device-to-device (and possibly device-to-server) RPC mechanism that is fast, reliable, and protective of developers and users alike.
This makes sense on the surface. It's too bad, however, that Google's engineers weren't able to complete work on such a vital API as one for Bluetooth.
Next up is GChat. GChat is Google's instant messenger client that Google users can use to chat with one another. Much hoopla is made over support for IM on mobile devices. Many people, for example, were disappointed that the iPhone didn't include an IM client when it was first released. GChat doesn't have the reach (right now, anyway) that AIM, Yahoo IM, or Microsoft's LiveChat have.
Another Google developer tells us why it has been dropped from the Android SDK for now. This is a lengthy explanation:
"Repurposing" Google Talk Friends Google Talk friends are intended for a different purpose than that envisioned by the GTalkService. Your Google Talk friends can contact you at any time via IM. They can see your email address and often can see your real name. However, the idea of a Google Talk friend does not always line up with the types of people who may want to interact with via an Android application. For example, imagine a really cool mobile Massively Multiplayer Online Roleplaying Game using GTalkService. You would have to add all the players to your Google Talk friends list in order to play with them. Next time you log in to Google Talk from your desktop or on the web, you would notice that you have many new "friends". You may not want to chat with these friends -- and perhaps worse, you may not want them to know what your real name or email is. We do realize that Android users will want to interact with other Android users anonymously and for short periods of time, especially in gaming scenarios. Unfortunately, it turns out that using Instant Messaging is not really a good way to do that.
Verifying Remote Intent Senders
Intents were designed to send messages within the device. The Intent subsystem can conclusively determine who sent Intents only when the Intents originate from the same device that services the Intent. When Intents come from other devices, the Intent subsystem cannot determine what application sent the Intent. This can lead to a variety of problems. 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. 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. In the end, we determined that the Intent system, as designed for local use, did not lend itself well to being the vehicle for a Remote Procedure Call (RPC).
Placing Too Much Security Burden on Developers
As originally designed, the GTalkService placed a significant burden on the application developer to avoid security flaws and perform user and relationship management. 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. There are automated mechanisms that could be used to help protect vulnerable applications or stop the spread of malware, but the deployment of these technologies was not possible in time for the launch of the first Android handsets.
These are all valid reasons, security being the most relevant reason for dropping GChat.
Hopefully, Google will be able to sort these issues out and get the APIs back into future versions of the SDK.
