Do androids dream of electric penguins?

In the decade since its founding in a Palo Alto garage, the name "Google" has become practically synonymous with the Internet. Thus it was that the search company's celebrated entry into the mobile market was met with significant enthusiasm from those who believed that Google would be able to use its immense resources and Internet savvy to produce a next-generation mobile product that would deliver "the cloud," in its vast entirety, into the eager hands of consumers. Some of the biggest names in the tech industry flocked to Google's banner and affirmed their support for the Open Handset Alliance, which promised to liberate the mobile masses by building a blooming garden without walls.

After the fanfare faded, we ended up with Android—a platform that launched with some limitations but nonetheless has significant potential. Although the first Android devices leave a lot to be desired when compared to competing products, the platform itself is evolving quickly, and it offers the advantages of openness and collaborative development. In this article we'll take a close look at the underlying technology of Android and what the platform means for developers.

Design philosophy

Although Android is built on top of the Linux kernel, the platform has very little in common with the conventional desktop Linux stack. In fact, during a presentation at the Google IO conference, Google engineer Patrick Brady stated unambiguously that Android is not Linux.

Much of the Android userspace operates within the constraints of Dalvik, Google's own custom Java virtual machine. Dalvik uses its own bytecode format called Dex, and is not compatible with J2ME or other Java runtime environments. Third-party Android applications are written in Java using Android's official APIs and widget toolkit. The Android SDK includes special compilation tools that will translate Java class files into Dex bytecode and generate an installation package that can be deployed on Android devices.

Android's radically different approach to mobile Linux application development offers some unique advantages, but it also creates a lot of challenges for third-party developers. The biggest advantage is that it provides a very high level of uniformity. In theory, the vast majority of Android applications will be able to run seamlessly on virtually any Android-based device without requiring any further modification.

The problem with Google's approach is that it makes Android an island. The highly insular nature of the platform prevents Android users and developers from taking advantage of the rich ecosystem of existing third-party Linux applications. Android doesn't officially support native C programs at all, so it won't be possible to port your favorite GTK+ or Qt applications to Android. It's also not possible to run existing MIDP applications on Android because it uses an incompatible virtual machine.

Other prominent mobile Linux platform initiatives have taken a very different approach and are making extensive use of existing desktop Linux technologies. Maemo, OpenMoko, ALP, MOTOMAGX, Moblin, and Qt Extended all provide some kind of portability glide path between the desktop and other mobile platforms. For example, it's trivially easy to port an existing GTK+ desktop application to Moblin, ALP, and Maemo devices.

The downside of the GTK+ approach compared to Android is that the GTK+ application will have to be modified to accommodate the hardware capabilities, form factor, and toolkit deviations for each individual device. Android attempts to circumvent that problem by providing its own universal runtime and toolkit. It is too early to judge whether Android's approach is successful because the number of Android-based devices is still somewhat limited.

The SDK and API

Android supplies a comprehensive and well-organized assortment of high-level APIs for building applications and leveraging the underlying functionality of the platform. The APIs provide an extremely high level of abstraction, which makes them relatively intuitive and easy to use.

Third-party applications can replicate or interface with virtually every major component of the platform. For example, Android provides methods for retrieving information from the user's contact list and for extending the contact system with new data fields. It's also easy to make a new dialer or implement custom behaviors for system events like incoming SMS messages. This is one area in particular where I really feel like Google exceeded expectations and delivered on its promises: The APIs truly make it possible to build applications that integrate fully with the rest of the platform.

The Android widget toolkit provides a lot of very useful components right out of the box. The individual widgets are designed specifically for finger-friendly interaction, with features like kinetic scrolling already built in. Developers use an XML-based user interface description language to specify the layout and attributes of the widgets, with the XML descriptions being loaded into the program through the Android resource system . The individual widgets described in the XML layout can be referenced by ID in the program. It's also possible to create widgets programmatically and manipulate the user interface at runtime.