In my previous post on the Google Handset Alliance I commented that Google have a large amount of work to do and that they have to catch up with Symbian and Microsoft in terms of OS capability, tools and documentation.
Now that the early look SDK has shipped I must say that I under-estimated how much Google has already done. (or was it mainly done by Android before Google acquired it?). Also, with the $10 million developer challenge and the active community (already forming teams for projects and Wikis) I now think what isn’t there, will soon be created.
Google has been very shrewd with the $10 million developer challenge. Although it seems a lot of money, it would only fund say 100 Google developers for a year. With the Challenge, it has many more developers developing for the platform.
When I think back to the early Microsoft Windows CE (Pegasus) and first Symbian SDKs, the Android SDK seems so easy to set up and use. No strange things to do to, for example, easy access the Internet via the underlying emulator host OS, few pre-install requirements, no post install fixes, few workarounds needed and no strange idioms.
It’s interesting that Google has chosen to create it’s own flavour of Java. I didn’t expect this because the existing Google Java apps are written in Java ME – why re-write them? As I mentioned previously, it turns out Android could also run a conventional Java ME VM so this may be less of an issue. It’s still not clear how Google’s VM will perform in multimedia (mobile TV?), games and real time applications.
I suspect all this about Java is a side issue anyway. Some people have already commented on the Android developers group that it’s possible to run compiled C/C++ on android. (although Google say you can’t). If the system really is open (or will be) then if you have a question ‘can it do xyz?’ then the answer will be ‘yes, do it yourself’.
The SDK documentation looks rushed in places (spelling mistakes, badly formatted pages and deprecated functions already) and there are holes in the functionality (no WiFi, localisation for example). However, the first look SDK is real ARM binaries actually running Linux and not just some limited emulated WINS UI thing that I expected. It should be enough to get Symbian and Microsoft thinking hard.
I would expect to see two classes of Android phone…
1. Open phones used by developers, early adopters and techie types. These might be produced by HTC or may even be existing ARM phones with new firmware. The functionality would only extend to that provided by the open source community.
2. Handset OEM phones with extra (licensed) commercial components and locked down to a greater extent.
I wouldn’t get too excited though. Most people I have spoken to think Android will just be another platform no more or less successful than Symbian or Windows Mobile.
Why would the mass market want to buy an Android phone? Why would a network operator sell an Android mobile phone over another? The phone may be 10% cheaper (estimate according to Google at Future of Mobile Conference) but I don’t see this as significant. The answer may lie in the Google engineering driven approach to everything. In one Google video I saw, the $10 million Developer Challenge is particularly looking for things that haven’t been done before. Maybe Google hopes new applications will cause people to want Android phones and, in turn, network operators to stock these phones.