March/April 2008

Android Calling

Continued from page 1

By Simson Garfinkel

The key to realizing this vision is a set of clean, documented, standardized interfaces that allow each part of the handset environment to interact with every other. For ­example, Android includes a so-called location provider interface. Services that might want to know where your handset is--such as Google Maps, navigation applications, or even ­special-­purpose applications that show you advertisements or offer you coupons based on your location--can use the interface to access technologies that can figure out where you are. These might include a GPS receiver built into your phone or a location service offered by your wireless provider.

This feature is good news for companies whose business model is based on providing information to consumers--and possibly showing them advertisements. It's terrible news for those whose business model is based on charging consumers to access hardware built into their own devices--the way Verizon does with its VZ Navigator, a navigation service that uses the GPS receiver standard in new ­Verizon phones and costs $9.99 a month or $2.99 a day.

An Architecture for Mashups
Does Android have what it takes to blow apart the silos in today's cellular-telephone marketplace and open it to the chaos of competition? Although the developer's preview is flawed, Android's architectural choices and development tools show great promise.

What's more, though Android itself is brand new, it draws from proven Google software. Consider Google Maps, which has been one of Google's most successful offerings to date. With little effort, practically any Web developer can create a "mashup" that drops geographical annotations like photos, routes, and notes about particular places onto a beautiful, interactive, and highly functional map (see "Second Earth," July/August 2007). Android might, because of the way it is built, be able to replicate the versatility of Google Maps with respect to the phone itself. Unlike conventional mobile operating systems, which see each application as an essentially monolithic whole, Android splits a given app into multiple parts, with well-defined interfaces between them. This makes it easy for developers to write ­component-­based applications.

Interestingly, Android's component-based structure could also extend battery life. On a system like Windows Mobile, programs spend a lot of time running in the background, where they use memory and drain the battery. With Android, only a tiny piece of each application should need to run at any time; the other parts could shut down. As a result, it should feel more responsive yet use less power.

Developing for cell phones is normally much harder than developing for desktops: because far fewer developers work with cell phones than with desktop applications, the tools are less polished and harder to use. With Android, Google has rewritten the rules here as well. Developers write Android applications in the ubiquitous Java programming language, so there are already millions of would-be Android programmers. The free Android developer kit includes a telephone emulator, which lets any developer with a PC, Mac, or Linux desktop write and test Android applications. The emulator even makes it possible to control the speed and quality of the simulated phone's network connection, allowing developers to see how their programs will behave on phones in poor coverage areas without having to load the applications onto real phones.