Google’s new operating system, Android, is not just a comprehensive runtime for mobile applications. Nor is it just a rapid application development platform for such applications. In addition to these things, I see Android as a redefinition of what interactive applications should be.

The snowstorm that covered Boston yesterday didn’t keep two hundred hackers from showing up this morning for Google’s Android Code Day, most of them probably hoping to take home a slice of Google’s ten million dollar challenge. Even more amazing, the Google team flying in from California also made it. We filled the ballroom of the swanky Charles Hotel, where attendees were interested less by the landmark oil paintings on the walls than by the images delivered by a wireless network to their laptops.

In this blog I’ll summarize some of the basic elements of Android applications and how they relate to componentization, today’s trend in software development.

The evolution of components

Development for mobile devices is dominated by concerns over limitations: notably limitations in memory, power, and screen real estate. The desire to conserve memory and allow applications to supplant each other seamlessly seems to drive the component architecture of Android.

Google explicitly describes an application on Android as different from what desktop users currently think of as applications. The Android introduction says:

You can think of an Android application as a collection of components, of various kinds. These components are for the most part quite loosely coupled, to the degree where you can accurately describe them as a federation of components rather than a single cohesive application.

A sophisticated runtime environment carries out this concept, hiding the standard Linux process model that underlies Android. Each Android application defines activities, and tells the runtime through a manifest file what each of its activities can do (open a URL, create a mail message, search a database of contacts or photos, etc.). Each of these links is called an intent, and the runtime creates a database of all the intents on the system. Other applications then invoke an intent when they need a service that they do not implement themselves.

Several years ago I wrote a series of articles, notably Applications, User Interfaces, and Servers in the Soup, exploring the implications of applications as collections of components. More recently I expressed and solicited opinions about the possibilities in The desktop I’d like to see.

Various comments on the latter article referred to precursors of such a desktop, and argued about whether componentization would be feasible or worthwhile. Now that Microsoft Office is thoroughly componentized and RESTful APIs bring the concept to everyday distributed applications, the day of the componentized user interface seems closer. KDE 4 also seems to be heading in this direction with its Plasma shell.

Today, presenters repeatedly asked the rhetorical question, “What is Android?” I see Android as a convenient development environment and powerful runtime for cooperating components.

Processes on Android are tightly managed, so applications must be prepared to die and be reborn. When the user or the application passes control to another application–such as by invoking an intent–the runtime calls an onPause() callback function supplied by the original application. It is the responsibility of each application, in its onPause() function, to save the state that would allow it to resume gracefully when the user returns to it. Now the system is free to kill its process to save memory, and the runtime restores the state when it restarts the application.

However, process management is lazy. A process that terminates is allowed to stay in memory in case the user restarts it in the near future, but the process can be purged to make way for new ones.

Long-running activities are supported where needed. A heavy-weight calculation can use a background thread, but if the user puts the application into the background and starts a new one, the application’s process is fair game for the system to kill, and the thread goes away with the rest of the application. Therefore, for persistent activities, Android offers separate processes called services.

As an environment for cooperating components, Android is replete with communication and data sharing mechanisms:

• An activity can register an IntentReceiver (the equivalent of event listeners in other systems) so that the activity is awakened or started when a particular system event takes place, such as an incoming phone call. Each IntentReceiver should run quickly and yield the processor. If the activity needs to do something heavyweight, it should run a lightweight IntentReceiver that starts a background service, rather as Unix and Linux device drivers are divided into top halves and bottom halves.
• The libraries provide data structures called Parcels and Notifications to pass data between functions and from applications to the runtime.
• Applications that shepherd data stores for other applications, such as contacts and photos, expose them through data structures called ContentProviders.
• Gtalk, Google’s communication protocol built on XMPP, is provided not only for instant messaging but for data-passing between applications on different systems.
• The Android Interface Definition Language (AIDL) facilitates the definition of data passed between services.

I do see some risks in the Android architecture. First, I imagine it would be hard to port existing applications from other environments, because Android rethinks application architecture so thoroughly. (I’m told, though, that there will be a compatibility layer for applications using J2ME’s Mobile Information Device Profile.) Furthermore, Android embodies conveniences that add overhead.

Efficiency in Android

Android applications are written in Java and compiled into an Android-specific bytecode interpreted by the runtime, which is called Dalvik. (Google expects other languages eventually to be ported to Dalvik’s bytecode.) I’m sure there is a penalty paid both for the use of Java instead of C or C++ and for using the interprocess communications (notably intents) described in the previous section. But Google presenters today listed several ways they cut down on runtime demands:

• Dalvik is register-based instead of stack-based, which makes it more efficient.
• Dalvik lets processes share system classes.
• An application can bundle a native library, but that library is used only with that application
• Android includes a libc based on OpenBSD and NetBSD libraries but adapted for an embedded environment. Although it’s probably present to support other standard libraries, it may be useful for developers trying to squeeze more performance from an application.

Android has run on phones with as little as 64 Mbytes memory, but is intended for 120 Mbytes or higher.

Android as both open and open-ended

Google’s announcement of Android followed on the heels of Apple’s release of the iPhone. Google did not manage to steal Apple’s thunder, because the carefully controlled iPhone interface remains the standard by which other interfaces are measured.

The iPhone’s API tells you what you can do and how each effect will be rendered, right down to available coloring. Android provides some structure in its graphics libraries, and a variety of panel types to help ensure attractive layouts as screen resolutions change, but as an open platform it leaves the developer a lot more leeway.

I’m hoping that user interface guidelines will appear soon, along with higher-level libraries to provide an attractive and standard look and feel. I imagine device manufacturers or service providers will jump into the breech with competing standards.

I’m uncomfortable when I think, as an historical analogy, that the wide-open X Window System took a couple decades to develop anything resembling a sleek and efficient look and feel. But I’m heartened to think that the Darwinian culling of interfaces will be faster on Android than on X, because Android is open. Unlike the early decades of X, where companies kept a firm hold over the toolkits and window managers, Android allows a user to install any window manager that catches his or her fancy.

The promise of openness

I have heard a lot more excitement over the concept of Android–and its support by a large number of equipment manufacturers, service providers, and software vendors in the Open Handset Alliance–than the APIs themselves. In a world of computing that seems inexorably trending toward openness, we’ll see whether the promise of Android gives it momentum.

Because Android will be released under an Apache license (as soon as Google feels the code has reached the 1.0 stage), application developers don’t have to release their source code. Even developers working on the challenge can submit binaries while withholding source code. This policy may facilitate participation.

The biggest promise of Android is to lower the barriers for participation in the mobile world so that we’ll hopefully see:

• Local businesses and other organizations offering Wi-Fi-based and Bluetooth-based services over municipal networks, disintermediating the expensive services provided by cell phone companies.
• Applications suited to developing countries, where mobile phone usage is popular and growing, but whose needs differ from the developed countries where most applications are currently written.
• Social networking and creative mash-ups in Web 2.0 fashion, creating new value that is bigger than the sum of its parts.