Google explains Advanced Bluetooth & GTalk API omissions

August 25, 2008
7

After the news of the latest Android SDK release, Google came in for some criticism over a number of APIs the company removed and that, as a result, would not be present in the eventual Android 1.0 platform.  Headlines suggested that Android would have no Bluetooth support, for instance, and the whole OS was accused of not being ready for primetime.  Now the Developers Blog have spoken up to explain two of the most prominent omissions - the advanced Bluetooth API and the GTalkService - and justify the reasons for their being (temporarily) left behind.

Despite the rumors, Android will support the usual array of Bluetooth headsets and dongles.  You'll be able to use it with your hands-free or tether it to your laptop (carrier T&Cs permitting).  What won't be there is the API that exposes Bluetooth functionality to developers:

"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" Nick Pelly, Android engineer responsible for Bluetooth API

That means, initially, developers won't be able to use Bluetooth for, say, short-range wireless gaming between Android handsets.  It's a disappointing omission, but the Android team are promising it'll make an appearance in a future release.

Secondly, the GTalkService API, which would have presented a straightforward interface for the exchange of messages between Android devices.  Rather than time shortages, it's security that scuppered that particular API, both of personal details (communicating with other mobile users would then see them added to your Google Talk friends list, whereupon they could see your email address and other information) and of application security.

"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" Dan Morrill, Developer Advocate, Android

Although on first glance it's easy to criticise Google for snipping out features, if poorly executed APIs led to future security or privacy breaches then the frustration would be even greater.


Recent Stories