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
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 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
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
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
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
to post comments)