
Google’s mobile OS has just lost a few features due to security and/or time concerns. The latest beta of the SDK misses two notable pieces of API:
Bluetooth
The Bluetooth API will also be missing from the initial release of Android. While this doesn’t mean that handsfree devices can’t be used (this will work), developers will not be able to access the transmitter.
The omission is due to lack of time - Bluetooth will be supported fully in the future:
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.
Google Talk
The Google Talk API has also been removed for a variety of security issues which would have allowed the device to be remote-controlled:
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.
As a final note, I want to point out that since the GTalkService was always a Google “value-added” service anyway, it was never guaranteed that it would be present on every Android device. That is, GTalkService was never part of core Android. As a result this change actually allows us the potential to build a new system that is part of the core of a future version of Android.
More info can be found on the Android Developer blog!