Dream(sheep++): A developer’s introduction to Google Android

Ars takes a close look at the technology underlying Google's Linux-based …

Building blocks

Android applications consist of content providers, services, broadcast receivers, and activities. These components all serve specific purposes in the Android application stack. The manner in which they can interact with each other is what imbues Android with its remarkable modularity.

Content providers

Content providers serve as an abstraction layer for interacting with various data sources and for sharing persistent data between applications. They expose information through a standardized query interface. Queries are described with a URI syntax, but developers typically use higher-level wrapper classes that generate and manage the query strings. When a program sends a query to a content provider, the response is a cursor object that gives the program database-like access to the underlying content. It is also possible to hook monitoring mechanisms into content providers so that your application can be notified when data changes.

The content provider system offers several significant advantages to Android developers. The most noteworthy advantage is that the system facilitates a high level of interoperability by allowing applications to share data in a very uniform way. Several key platform data sources—including the Android contact list and multimedia storage systems—are exposed through content provider interfaces by default so that they can be easily leveraged from third-party applications.

Background processes

A significant feature that differentiates Android from the iPhone platform is that Android officially supports background processes in third-party applications. These are implemented with Android's service component. (Services are headless operations that run in the background for extended durations.)

An interprocess-communication mechanism facilitates communication with services. The Android Interface Definition Language (AIDL) is used to describe the programmatic interface of the methods that the developer wants to expose through the IPC system. During the build process, the AIDL files will be used to automatically generate Java stubs.

Broadcast receivers

Android's broadcast system is roughly analogous to the concept of D-Bus signals on the Linux desktop. Developers implement broadcast receivers which can detect when specific system messages or events are emitted and perform certain behaviors in response. Programs emit their own messages that can be intercepted by other applications.

Many underlying system events can be monitored with the broadcast system, so it can be used to hook into things like battery status changes, incoming SMS message arrival, hardware button presses, GTalk connection changes, storage mounting, and screen blacking.

Intents

Android's "intent" system is the key to understanding how all of these pieces are used together. Intent objects—which contain an action ID and a data URI—are used to invoke activities, services, and receivers. The action ID specifies a desired behavior, and the optional data URI provides the location of the data on which the action should operate.

For example, if an application wants to launch the dialer and punch in a phone number, it would perform ACTION_DIAL and provide the phone number as either a telephone URI (such as tel:8888888888) or an address book provider URI (such as content://contacts/1). The resulting intent object can be executed by passing it to the startActivity method.

For testing purposes, there is a really useful utility called Intent Playground that will let you invoke arbitrary intents. It even has autocompletion for actions, which makes it a great way to explore the intent system.

Learning more

From the perspective of a programmer, these components of the Android platform necessitate an approach that is radically different from conventional desktop development in many ways. Android is built on a different set of paradigms with new nomenclature, and it is endowed with unfamiliar capabilities and limitations.

All of this newness can make the platform seem a bit intimidating, even to veteran Linux and Java developers. The significance of the individual pieces and the relationships between them aren't always clear at first, so the richness of Android's modularity and flexibility aren't immediately apparent from the surface. There is a lot there to learn, and there are still many aspects of the platform that I haven't delved into with sufficient depth myself.

It's very difficult to convey the true nature of the platform through a top-down overview. In order to really comprehend how it all works and cultivate a more complete understanding, I encourage you to dig in for yourself and experiment. Although the initial learning curve is steep, it gets a lot easier once you have developed a solid grasp on the basics. This is because virtually all of the platform's advanced functionality is exposed in a somewhat consistent way through internally standardized mechanisms.

Open platform

One of the distinguishing characteristics of Android is that it's a very open platform. When Android was first announced, Google promised that the Open Handset Alliance would bring unprecedented openness to the mobile industry. At the LugRadio Live event earlier this year, Google developer Robert Love told the audience that "the goal of Android is to be open to developers, open to the industry, and open to users."

Although Google espoused some lofty ideals during the early stages of development, the company's conduct prior to release fell short in many ways of what was promised. The development process took place entirely behind closed doors, and the only players that had input were Google's business partners. The entire undertaking lacked inclusiveness, and many details about the platform itself were kept tightly under wraps. The vast majority of third-party developers were left out in the cold and were denied access to SDK updates for months while Google's programming contest finalists were given the latest versions under non-disclosure agreements.

This situation alienated some members of the third-party developer community. Several of Google's own engineers were also deeply frustrated with the way that things had unfolded, and they attempted without success to lobby internally for more transparency.

As Google originally promised, things improved dramatically after the launch of the G1. The source code for the entire platform is now open, and Google has published extensive documentation that describes how independent developers can contribute to the project. Those changes in the development process make Android a truly open and participatory project. Patches from external contributors have already been accepted, and Google is also working closely with upstream projects like Harmony.

After the source code was opened, there was still one critical weak spot: the T-Mobile G1, Android's flagship handset, is a closed device that uses code signing to restrict changes to the platform. There is no way to flash the G1 with modified images, which means that platform hackers have no practical way to test their changes on physical hardware. This limitation was an immense disappointment, and it undermined a lot of the value of having an open mobile platform. To address this deficiency, Google launched its own unlocked developer model of the G1 handset. The hackable Google handset, which is available to anyone who registers with the Android App Store, is a fully open device that can be flashed and modified.

Despite a very rough start, Google has fulfilled most of its openness promises. It has delivered an open platform and is making available an open device for developers and enthusiasts who want maximum flexibility. In retrospect, it seems like the lack of transparency that plagued the project prior to the launch of the G1 was largely the consequence of a relentlessly intense timeline and pressure from the mobile carriers and other partners. Google probably overestimated the amount of leverage it would have with its launch partners, and was forced to make serious compromises along the way in order to get a product to market in a timely manner. Now that the G1 has landed, Google is doing its part to remedy the mistakes and accommodate the third-party developer community.

This is all more or less acceptable for a first product, but developers can and should expect more transparency in the future. Fortunately, it seems like Google is on track to deliver that. The source code of the next major version of the Android platform is already accessible to third-party developers.