A few days ago Google has finally released a new version of the Android SDK. The version number of this new versione is 0.9 and it seems that we are slowly approaching the first official release of Version 1.0.

The post of the announcement can be read by following this link pointing to the official Google Android weblog.

As you can read in the official post there are tons of changes in the latest SDK:

First and most obviously, the new Home screen is included, along with a ton of UI changes for 1.0.

Some new applications are included: an Alarm Clock, Calculator, Camera, Music player, Picture viewer, and Messaging (for SMS/MMS conversations.)

Several new development tools were added, such as a graphical preview for XML layouts for users of Eclipse, and a tool for constructing 9-patch images.

Since we’ve got a new Home screen application now, we thought the now-obsolete version from the M5 early-look SDK might be helpful to developers, so its source is included as a sample.

A number of new APIs are fleshed out and improved, and others are now close to their final forms for 1.0.

Tons of bugs were fixed, of course. (If you had problems with the MediaPlayer, try it now!)

This is definitely good news even if there are still some shadows on the Android release plans.

Unfortunately some APIs have been removed in the Beta SDK and are not planned to be present in the upcoming 1.0 release.

Some more information on this removal can be found in another blog post at the Google Android weblog: Some informations on APIs removed in the Android 0.9 SDK Beta.

This is really bad news.

If we look at the mobile Operating System market Bluetooth is very common and we are not really talking about some new technology. Blueetooth has been there for years and there are plenty of Blluetooth stacks out there that are perfectly working.

The official explanations states that:

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.

From a technical standpoint this is a great explanation on what was going on. From a marketing standpoint this is a very bad statement.

Even if standard handsfree device like bluetooth headsets will work with a Google Android mobile phone, developers will not be able to develop applications using bluetooth.

The second API that Google has decided to remove is the GTalkService API.

This is the reason:

1. “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.
2. 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).
3. 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.

Again, fine from a technical standpoint and bad from a marketing standpoint.

At the end of the day these are strong messages to the market. You announced a platform with a list of features and API and in the development process you realize that you will not be able to ship those features and API in the first official release. Bad.

I know that trying to deliver a new Operating System for a mobile phone is a complex and difficult task but at the end of the day we are talking about Google. They should know how it works.

I still strongly believe in Android but every day lost in favour of Symbian, Windows Mobile and the iPhone OS is a day that you will not recover. This means loosing market share.

Apart from Market Share there is another point that can create problems.

You may loose developers and if you loose developers on a new operating system you are going to be dead.

Already in the past we have heard complaints from Android developers about bugs and issues with the first releases of the SDK. A lot of them decided to move to more mature platforms and I can understand their decision. They have to pay bills with the software they write.