.Dust

A few days ago Google has finally released a new ver­sion of the Android SDK. The ver­sion num­ber of this new ver­sione is 0.9 and it seems that we are slowly approach­ing the first offi­cial release of Ver­sion 1.0.

The post of the announce­ment can be read by fol­low­ing this link point­ing to the offi­cial Google Android weblog.

As you can read in the offi­cial post there are tons of changes in the lat­est SDK:

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

Some new appli­ca­tions are included: an Alarm Clock, Cal­cu­la­tor, Cam­era, Music player, Pic­ture viewer, and Mes­sag­ing (for SMS/​MMS conversations.)

Sev­eral new devel­op­ment tools were added, such as a graph­i­cal pre­view for XML lay­outs for users of Eclipse, and a tool for con­struct­ing 9-​patch images.

Since we’ve got a new Home screen appli­ca­tion now, we thought the now-​obsolete ver­sion from the M5 early-​look SDK might be help­ful to devel­op­ers, so its source is included as a sample.

A num­ber of new APIs are fleshed out and improved, and oth­ers are now close to their final forms for 1.0.

Tons of bugs were fixed, of course. (If you had prob­lems with the Medi­aPlayer, try it now!)

This is def­i­nitely good news even if there are still some shad­ows on the Android release plans.

Unfor­tu­nately some APIs have been removed in the Beta SDK and are not planned to be present in the upcom­ing 1.0 release.

Some more infor­ma­tion on this removal can be found in another blog post at the Google Android weblog: Some infor­ma­tions on APIs removed in the Android 0.9 SDK Beta.

This is really bad news.

If we look at the mobile Oper­at­ing Sys­tem mar­ket Blue­tooth is very com­mon and we are not really talk­ing about some new tech­nol­ogy. Bluee­tooth has been there for years and there are plenty of Bllue­tooth stacks out there that are per­fectly working.

The offi­cial expla­na­tions states that:

The rea­son is that we plain ran out of time. The Android Blue­tooth API was pretty far along, but needs some clean-​up before we can com­mit 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 exam­ple of the prob­lems in the API. Client code is required to pass around IBlue­toothDe­vice­Call­back objects in order to receive asyn­chro­nous call­backs, but IBlue­toothDe­vice­Call­back is meant to be an inter­nal inter­face. That client code would break the moment we added new call­backs to IBluetoothDeviceCallback.aidl. This is not a recipe for future-​proof apps.

To make things even more tricky, the recent intro­duc­tion of the bluez 4.x series brings its own new API. The Android Blue­tooth stack uses bluez for GAP and SDP so you’ll see more than a pass­ing resem­blance to bluez’s inter­faces in Android. The bluez 4.x change requires us to care­fully con­sider how to struc­ture our API for the future. Again, remem­ber that once we set­tle on an inter­face we need to sup­port it for years going forward.

From a tech­ni­cal stand­point this is a great expla­na­tion on what was going on. From a mar­ket­ing stand­point this is a very bad statement.

Even if stan­dard hands­free device like blue­tooth head­sets will work with a Google Android mobile phone, devel­op­ers will not be able to develop appli­ca­tions using bluetooth.

The sec­ond API that Google has decided to remove is the GTalk­Ser­vice API.

This is the reason:

1. “Repur­pos­ing” Google Talk Friends
   Google Talk friends are intended for a dif­fer­ent pur­pose than that envi­sioned by the GTalk­Ser­vice. Your Google Talk friends can con­tact you at any time via IM. They can see your email address and often can see your real name. How­ever, the idea of a Google Talk friend does not always line up with the types of peo­ple who may want to inter­act with via an Android appli­ca­tion. For exam­ple, imag­ine a really cool mobile Mas­sively Mul­ti­player Online Role­play­ing Game using GTalk­Ser­vice. You would have to add all the play­ers to your Google Talk friends list in order to play with them. Next time you log in to Google Talk from your desk­top or on the web, you would notice that you have many new “friends”. You may not want to chat with these friends — and per­haps worse, you may not want them to know what your real name or email is. We do real­ize that Android users will want to inter­act with other Android users anony­mously and for short peri­ods of time, espe­cially in gam­ing sce­nar­ios. Unfor­tu­nately, it turns out that using Instant Mes­sag­ing is not really a good way to do that.
2. Ver­i­fy­ing Remote Intent Senders
   Intents were designed to send mes­sages within the device. The Intent sub­sys­tem can con­clu­sively deter­mine who sent Intents only when the Intents orig­i­nate from the same device that ser­vices the Intent. When Intents come from other devices, the Intent sub­sys­tem can­not deter­mine what appli­ca­tion sent the Intent. This can lead to a vari­ety of prob­lems. At first, remote appli­ca­tions could send arbi­trary Intents, mean­ing that your Google Talk friends had almost the same con­trol of your device as you did. Even once that issue was resolved, we rec­og­nized that we could not trust the iden­tity of the appli­ca­tion who sent the request. We could only trust the iden­tity of the user. So a “bad” appli­ca­tion on your friend’s device could send a mes­sage to a “good” appli­ca­tion on your device which would neg­a­tively affect the good appli­ca­tion. In the end, we deter­mined that the Intent sys­tem, as designed for local use, did not lend itself well to being the vehi­cle for a Remote Pro­ce­dure Call (RPC).
3. Plac­ing Too Much Secu­rity Bur­den on Devel­op­ers
   As orig­i­nally designed, the GTalk­Ser­vice placed a sig­nif­i­cant bur­den on the appli­ca­tion devel­oper to avoid secu­rity flaws and per­form user and rela­tion­ship man­age­ment. An Android appli­ca­tion using GTalk­Ser­vice would be reach­able from all of the user’s Google Talk friends, and a flaw in that appli­ca­tion could pose an invit­ing tar­get to a mali­cious “friend” or auto­mated mal­ware. There are auto­mated mech­a­nisms that could be used to help pro­tect vul­ner­a­ble appli­ca­tions or stop the spread of mal­ware, but the deploy­ment of these tech­nolo­gies was not pos­si­ble in time for the launch of the first Android handsets.

Again, fine from a tech­ni­cal stand­point and bad from a mar­ket­ing standpoint.

At the end of the day these are strong mes­sages to the mar­ket. You announced a plat­form with a list of fea­tures and API and in the devel­op­ment process you real­ize that you will not be able to ship those fea­tures and API in the first offi­cial release. Bad.

I know that try­ing to deliver a new Oper­at­ing Sys­tem for a mobile phone is a com­plex and dif­fi­cult task but at the end of the day we are talk­ing about Google. They should know how it works.

I still strongly believe in Android but every day lost in favour of Sym­bian, Win­dows Mobile and the iPhone OS is a day that you will not recover. This means loos­ing mar­ket share.

Apart from Mar­ket Share there is another point that can cre­ate problems.

You may loose devel­op­ers and if you loose devel­op­ers on a new oper­at­ing sys­tem you are going to be dead.

Already in the past we have heard com­plaints from Android devel­op­ers about bugs and issues with the first releases of the SDK. A lot of them decided to move to more mature plat­forms and I can under­stand their deci­sion. They have to pay bills with the soft­ware they write.

Related posts:

1. Google Android Optional APIs
2. Google Android SDK Released
3. Apple iPhone And The Yet To Be Announced Google Phone
4. Google, It’s A Plat­form Not A Mobile Phone
5. Google App Engine Is Here!