Google Android - a sneak preview
What's in it for developers?
Android lacks APIs for useful features like the ability to pull the signal strength out of adjacent cells to do location, or read the camera directly. There may be a future path to allow C development, but initially this will be in the form of private libraries which are only available to your Dalvik application. Google has experimented with this to port Quake to Android. Dalvik is, of course, Open Source (under an Apache 2.0 license). But in practice, the restriction of all development being within Dalvik draws the line on what is open and what is closed in a very interesting way.
It's "Open" because you don't need permission to ship an application. Developers can integrate, extend and replace components and users don't need permission to install an application. The installer is part of the platform, along with a roll-back and un-install. But Android is not (yet) open beyond Dalvik.
As with the last attempt at an industry standard operating system, SavaJe, the application framework is written in Java. This is not necessarily a bad thing: it has served RIM well. As for the look and feel, it's still in progress. Google provides Home, Contacts, Phone and Browser applications, but these are not mandatory - nothing is - and Google expects ODMs to supply their own. This again marks out Google as a computer company looking at mobile, rather than a true mobile company. No-one in the mobile industry would prioritise the browser over messaging. Text message revenues have kept many a network solvent, and for quite a lot of users they are more important than voice.
There are no secret, privileged or protected APIs but developers are not bound to publish APIs to their apps. They can of course do so if they choose to and it's encouraged. Alliance members have signed an anti-fragmentation agreement, they will contribute back GPL like. This is not binding and doesn’t cover applications. There might be some branding incentive based on manufacturers ability to call something an "Android compatible" handset. There is nothing to stop a phone manufacturer or one developer modifying code in a way that will inadvertently break an application. The user always owns the experience, in theory the operator could lock the home screen but this would go against the morals of the Open Handset Alliance.
Activities that will cost the user money - such as making a call or sending a message - fall into a special category of application that require user permission. There is no signing procedure; security is up to the user. Some networks won't be happy with this, because as one developer at the event pointed out "people are stupid". There are however some dialer-specific security protections to warn the user what is going on.
Sponsored: Benefits from the lessons learned in HPC