Google's phone initiative: Android

The media frenzy over Google's Android announcement has subsided, a bit, with actual details of the platform and strategy starting to emerge. Android is the long-rumored gPhone in a very different guise; instead of creating a phone, Google has created the Open Handset Alliance (OHA) – bringing together more than 30 different hardware and software companies – to develop a platform for mobile phones. That platform is Android, a Linux-based, Java-programmed framework for developing mobile applications. With this week's release of the Software Development Kit (SDK), we can now see some sample code as well as seeing how Google intends to attract developers to the platform.

Google has a stated intent to release "most of the components" of Android under the Apache v2 license, but the "early look" SDK has a much more stringent license. The license terms appear to give the OHA and Google some wiggle room regarding pieces of the software that they may not be willing or able to release under the Apache license, but a strict reading will worry free software folks. Some of the components of Android, Linux in particular, are released under other licenses, so the most charitable interpretation is that "most" is referring to those non-Apache-licensed components, but it will be a while before we know.

The SDK comes with lots of sample code for applications, but none for the tools that come with it; that will presumably come later. Probably the most interesting piece of Android is the Dalvik virtual machine (VM), which handles running the Java applications, but is not a Java virtual machine (JVM). Instead, Dalvik takes the .class and .jar files produced by the Java compiler and turns them into Dalvik executable (.dex) files.

Dalvik is a register-based VM – unlike Java's stack-based implementation – that was created with a focus on minimizing the memory footprint. There may be optimizations possible with Dalvik's model that are not possible for JVM bytecode, but there may also be another motive for Android having its own VM: it is not subject to the Sun-controlled Java Community Process. Google is trying to leverage developer knowledge and understanding of the Java language and class libraries, without, necessarily, rigorously following the Java "standard".

Android uses the Apache Harmony class libraries to provide compatibility with Java Standard Edition (Java SE). There is an ongoing dispute between the Apache foundation and Sun regarding certification of the Harmony code as Java SE compatible, but that appears not to be much of a concern for Google and the OHA. It will be interesting to see if Sun's recent patent beliefs extend to implementations of Java SE that might infringe their patents.

Java Micro Edition (Java ME) runs on a large number of mobile phones today, but has been fragmented by the various phone vendors, breaking the (mostly illusory) "write once, run anywhere" promise that Java popularized. Though an Apache license won't prohibit that kind of fragmentation, the OHA requires its members to agree not to fragment the Android platform. That agreement has not been made public and likely lacks any teeth to punish violators, but it does serve as a statement of intent. It is clear that Google and the other OHA members have learned from the Java ME implementations in current phones and have something fairly different in mind.

The key to success of the Android platform will be in the applications that get built for it. If Android phones have enough unique and interesting tools, customers will seek it out – at least in theory. The early release of the SDK, long before real hardware is available, is part of the strategy to attract developers. Google has also put up $10 million for bounties as part of the Android Developer Challenge. Developers can enter their applications until March 3, with the best 50 receiving $25,000 each. Those winners will then be eligible for even larger, six-figure, awards after handsets are available in the second half of 2008.

Money is certain to motivate some to write Android applications, but an easy-to-program interface based on an open platform will be enough for others. Android is definitely being touted as being easy to develop for, with one of the introductory videos showing a few sample programs that were claimed to be completed in a day. The SDK comes with an emulator that allows developing and debugging without access to phone hardware. Screenshots of different emulator "skins", which represent different hypothetical handset models, accompany this article.

The project community is, unsurprisingly, hosted at code.google.com. The site is already active, just a few days after the release, with an impressive amount of documentation available. The discussion group has quite a bit of traffic with questions, bug reports, and ideas for additional functionality. One recent poster had ported busybox to Android, making all of the normal UNIX command-line tools available in the emulator.

Android is a bold move that strikes at the heart of some entrenched interests, most notably Sun, but Apple (perhaps only recently entrenched) as well. Other mobile phone OS vendors, Symbian and Microsoft for example, could be hurt by widespread Android adoption as well. There is the ever-present threat of patent litigation getting in the way, but the backing of Google and the other OHA members should help to blunt that kind of attack. The real question is whether Android offers something compelling to both developers and users. The handset makers and cellular carriers will also need to do more than just join an alliance too; phones will need to be created and sold.

Unfortunately, the real losers in this could be OpenMoko and Qtopia. Both are free software platforms for mobile phones, but neither has been able to generate the publicity that Google has. At a fundamental level, Android takes a different approach, requiring all applications to run atop Dalvik, whereas OpenMoko and Qtopia both allow for native code, compiled from C or C++. Each allows the possibility of porting applications from other platforms, but it is likely that there are far more mobile phone Java applications than the others, which might give Android a leg up. It is certainly possible to run a Java VM (or even a Dalvik VM) on OpenMoko or Qtopia, which might open those platforms up to more applications, but the Android initiative has the appearance of a juggernaut – at least in the early going.

Java may offer some security advantages as well. Native code cannot be sandboxed easily so it will be easier to write malware for platforms that support it. The mobile phone malware "industry" is still in its infancy, but we can expect to see more of it as more sophisticated phones get into the hands of more security-unconscious users.

While iPhone users still wait for the ability to build applications for their phone, free software users have multiple choices of development platforms. The Neo 1973 hardware from OpenMoko is getting closer to availability for end users, with at least two software stacks available. It certainly wouldn't be too surprising to see Android ported to the Neo as well, though no official word has been heard as of yet. It is an exciting time for free software and for mobile phone users as we have just begun to see what the community can do in this space. With luck, there will be room for multiple free mobile platforms, avoiding a monoculture, as well.

---

(Log in to post comments)

I guess it's not possible to say if it will be possible to do a completely free Android phone
(with exception of GSM chipset)? Some manufacturers will choose not to, but it would be nice
to know if it is possible at all.

If it's not possible, this is not really a competitor to OpenMoko. But it is going to put
resources to those free software components that will be used in Android phones, so yet again
it should help more free efforts like OpenMoko to build their next platforms more easily. Even
Nokia's Internet Tablets have helped eg. GTK, GStreamer et cetera, even though the Internet
Tablet OS is a closed source OS with the exception of maemo components.

What OHA seems to be doing right is that they are considering community as important aspect.
This will definitely be an interesting platform, and my interest is only depending on how open
it's actually going to be - namely are there artificial limits or not to the usage of the more
free Android devices. Until that is resolved, it's quite clear OpenMoko and Neo1973 is where
my interest is.

I know it's just words at this point, but the following promise sounds quite good:
http://groups.google.com/group/android-developers/msg/ce8...

"When the source code is released, it will include the entire system. ... Source will be
available for the system C library, the Dalvik VM, the core API libraries, etc."

Could this make porting the Dalvik VM to a different environment plausible?

The concepts seems pretty interesting; maybe the VM could be ported for use in more generic
embeded environment, or even regular desktops/servers?

I wonder how Dalvik compares to Parrot, the other free software register-based VM.

I've been following OpenMoko for a while and rooting for it to succeed, but Android might be a
better solution simply because C/C++ scares a lot of developers.

The best thing to happen for FIC is to get Android running on their hardware so the success of
Android doesn't mean the failure of FICs open handset line.

I think it's too early to tell whether or not the success of Android means the failure of
OpenMoko, it might be that the two platforms are different enough to appeal to two different
segments of the developers.


I've often discussed the possibility of having Google crush TomTom, Garmin and the other gps
navigator players with an initially cheap phone with access to google-maps and a little bit of
cache.

Where TomTom et. al. need to sell the entire lump of map material (expensive) and update it
rarely for yet more money, an online GPS navigator could download only the data needed to
complete the trip and the initial cost could be much closer to that of a normal phone with the
map data being paid for on a pr. trip basis.

I'm sure phone companies would love to work with the map provides on making the billing easy
for the customer.

gps services is offered by most operators in sweden.
at least telias service works more or less exactly like you say.

Does the phone then work as a regular gpsnav unit, with turn by turn directions and all?

... or is it more like a printout of Google maps?

They're not actually using Google maps in the phones afaik, so you use them like a regular GPS
with turn directions and all. From what I've seen they're still a bit buggy and the GUI is too
slow (it's Symbian after all ;) ) so a regular GPS is still better, much like a compact
digital camera is better than a phone. 

Do you really think the impact of Android on OpenMoko or Qtopia can be negative?
It seems to me they are pretty different in fact from a technical point of view: Java vs. C,
selecting WiFi chipset based on availability of documentation/driver code vs. just use
(Google's) WebServices, lobbying to get GPS/GSM firmware open vs. conspiring against Sun's
power on Java, rebuild your entire flash image vs. download our .dex, etc.

If they are real competitors, don't we need a detailed side by side technical comparisons of
both platform now then, in order to quickly see which one really fits?

Well from what I've seen there is a whole bucket-load of C/C++ code that is needed to run
Android. 

The java-like stuff is only used in the high-level things.. Window management, package
management, and that sort of thing. Aside from that all the drivers and such are going to need
to be present on Neo1973.

Most of them may already be.. Like the OpenGL-ES support may be Mesa. That way google can use
software 3D or accelerated 3D based on what hardware is availiable. But other dependancies,
like the media codecs, are almost certainly not.

I really want Android to succeed, but with so many different handset manufacturers
implementing Android on a range of hardware, I imagine that the Android platform will be
different on every phone. That will be a huge headache for software developers. I read that
Jamdat, the game company that made big money with a bowling game, had 100+ "builds" of the
same J2ME game to accommodate all sorts of phone and JVM bugs.

Compare with the iPhone platform which is controlled head to toe by Apple (and admittedly
closed at the moment).

Google will likely simply keep most of it proprietary, while throwing a bone a two to
different open source projects every now and then, to keep the hope alive that it may be
released under an open source license some day.

Google already pushed back the release of Android's source code to late 2008, which has the
convenient side effect of keeping OpenMoko and Maemo from being able to offer Android support
on platforms that are not controlled exclusively by Google, like OHA's.

I expect it to splinter, as the phones from competing manufacturers are sold one their
differentiation, not on their similarity. Apple has a much better story with their own iPhone
platform, as there is only one kind of devices per generation. 

Besides, Apple's customers have enough disposable income to happily blow 400€ on a phone
gadget without blinking, so Apple does not need to do anything to attract developers: the
iPhone is where the phone end user application money will be easiest to collect from February
on, and I assume that's what forced Google's hand to release Android now, as it is, without
hardware, etc.