Google Android - a sneak preview
What's in it for developers?
Who mans the helpdesk?
Testing is always a major issue. To help reduce this, there is a class called 'instrumentation', which lets you run tests by generating fake, automated inputs. Android has a 'manifest', which is a bit like the Windows Registry. When an application requires a service (send an SMS, browse for a picture) it looks to see which applications are listed in the manifest to serve this. The end user will see a dialogue asking which application to use. Application developers are encouraged to publicise what intents they can support. This will probably take a bit of working through.
In this odd new space where the devices are pocket computers and not mobile phones, some interesting issues arise. Do you want a consumer to have to sign on to every application? They have to, since there is currently no single sign-on API in Android. How do consumers find new applications? A discovery mechanism for route to market is being worked on very hard, we learned. Who supports the application? What if my application is broken by another?
Google anticipates something like the PC model where you go back to whoever you bought the program from, as being the way forward. In practice most consumers will call the person they got their bill from - the network - and this single fact (with an average tech support call costing about $10 to service) might scare the networks off Android. Orange and Microsoft trained thousands of operators on Windows mobile before the first SPV shipped. Let's hope that the Geek Squad get up to speed on Android quickly.
To encourage developers there is a $5m challenge which has had its deadline extended to 14th April. There will be a challenge II after devices go on sale. Only the .apk file and docs need to be submitted, no source code needed and source can stay private and the developers keep the IPR.
We'll see a major new release of the SDK in the next couple of weeks. This will show a new user interface and include new APIs and improvements to others. Development is run under the system emulator. This is a full system image - much like is used for Qualcomm's UI One. The tools seem to be excellent.
Niche or riches?
But what really matters is sales. The mobile phone market is huge, but only a tiny fraction belongs to the kind of expensive devices which will run Android. Google suggests a minimum specification of a 200MHz ARM9, with 64Mb RAM and 64Mb Flash. We all know what minimum specs mean.
Other comments indicate that they expect a hardware MMU and hardware graphics acceleration. And it wasn't disclosed if that whole 200MHz CPU is needed for Android, or if the baseband and telephony stacks runs within that. Still, a sensible guess puts it in the same class as an N95 (think over £300 retail, SIM-free). So this is a small part of the market and a very crowded one, with the mainstream phone manufacturers Nokia, Samsung, Sony Ericsson and Motorola plus Blackberry, HP, Palm, HTC and of course Apple as major competitors.
Selling enough Android phones to make it worth a developers while in this environment is at best going to take a long time and at worst be a tough call. Most of the attendees were taking a break from their day-jobs. None seemed to think that they will be paying the bills with their killer Android application anytime soon.
The first devices will ship the second half of this year, so we can expect to see something announced at Barcelona.
The odds are stacked against any new mobile OS, and from Newton to Taos to SavaJe there isn't exactly a glittering record of success. What Google really brings to mobile is a brand and a can-do attitude. Only time, a lot of time, will show if it’s enough. If it's not my free T-Shirt will become a prized possession. ®
Sponsored: DevOps and continuous delivery