Google invited developers to its London office for one of three workshops - the others being in Munich and Tel Aviv to spread the word and teach developers how to write for their new OS. Another event will be held in Boston on February 23rd (check at the blog for an announcement). Here's what they told us. The mantra for Android is that it’s "a complete and modern embedded OS, with a cutting edge mobile user experience, a world class software stack for building apps and open platform for developers users and industry". That of course breaks into lots of different specifics some of which are more solid than others. Computer people coming to mobile have a very different view of phone architecture to phone people adding features. Phone people see the phone functions - the GSM chipset, Bluetooth, DVB-H, for example, as a foundation, with drivers on top. Then there's an abstraction layer, an operating system, a user interface framework and the applications on top.

Computer people look at the system as a processor with a BIOS on top, then an OS, framework and applications. The bits that mobile phone people see as a foundation, the computer people see as an adjunct connected by drivers. Voice is just another application. And this approach was reflected yesterday.

Google are computer people. In this model Google’s openness does go all the way down, with lots of the proprietary bits off the side. In a phone model, Google only does the top layers.

What's included - and what's missing

The lowest level of this is a Linux 2.6 kernel which works as a Hardware Abstraction Layer to support the memory management, display driver, camera driver, Bluetooth, flash memory, USB, keypad, audio and power management. Note, this doesn't by itself let you get at the GSM stacks and chipset. Google is therefore reliant on the hardware vendors to supply drivers, or at least the tools to allow developers to write the drivers. With Qualcomm, Intel, Marvell, Broadcom and Texas Instrument as partners, that's quite optimistic.

Google supplies a number of libraries including the Surface Manager, which is the system that controls what goes into the framebuffer (the system manager for 2D primitives); a media framework (provided by Real), SQLlite, openGLS, Freetype, Webkit, SGL, SSL, IBC. Developers reported that 2D was faster using OpenGL than SGL, but as we've not yet seen real hardware, this will be down to the implementation.

Google is pleased with the speed of their software 3D rendering, but really expect that devices will ship with hardware acceleration. Some developers were worried about testing on lots of different screen resolutions. In practice this is less of a problem. The display manufacturers only make a limited number of sizes. The basic ones – 96x64, 128x128 and 128x160 are all too small for a smartphone. You might get a few at 176x220, but the vast majority of Android phones will be 320 x 240.

The real magic is the Android runtime called Dalvik. This is a custom virtual machine designed to be a better embedded OS. It's a register-based Virtual Machine, and therefore more efficient in an embedded environment than a traditional Java Virtual Machine; core libraries interact with the Java Harmony project. You may write in Java, but the byte code is Dalvik.

Dalvik uses .dex byte code files and Java class files are converted to .dex. The .dex structure allows processes to share system classes, saving memory.

It might be better optimised for the ARM foundation of a mobile phone but it sacrifices the maturity of J2ME, which has been through more than a decade of growing pains and has a lot of add-ons in the form of JSRs (Java Special Requests). Dalvik will have to re-invent all that. Some of the Open Handset Alliance members are JVM companies, and we'll see a traditional JVM for Android.

So all initial Android development is in Dalvik, thus disappointed many of the developers who were looking for a system which was better at hitting the metal of a phone than Symbian.

What's missing

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.

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. ®