Google Calling: Inside Android, the gPhone SDK

On November 5^th, Google executives introduced the Open Handset Alliance (OHA)—a multinational group of 34 companies. The alliance was assembled to build a better mobile phone. A major part of this effort has been the development of the Android platform, described as "the first truly open and comprehensive platform for mobile devices…a fully integrated mobile "software stack" that consists of an operating system, middleware, user-friendly interface and applications." An important objective is to deliver a vastly improved web experience on mobile devices, equal to what people can experience on a desktop computer, in contrast to the limited functionality on today's mobile phones. The alliance is "committed to commercially deploy handsets and services using the Android Platform in the second half of 2008." Google promised the Android SDK by November 12th. This article covers freshly released details describing the Android platform and SDK.

The OHA was constructed from key stakeholders in the mobile ecosystem, including leading mobile operators, handset manufacturers, software companies, semiconductor companies, and commercialization companies. The OHA presently includes representatives from the largest mobile operators in the world, the leading handset manufacturers, the world's best software and semiconductor companies, as well as innovators in commercializing all of this cutting edge technology. Most importantly, this alliance remains open to other companies who have yet to join. If any group can change the way the mobile phone business works, the OHA can. Still, there was one ingredient missing: open source developers. With the release of Google's open source Android Platform SDK, now you have a voice in the game too.

Walt Mossberg, a keen technology observer, described another market driver in his October Wall Street Journal opinion, titled "Free My Phone:"

A shortsighted and often just plain stupid federal government has allowed itself to be bullied and fooled by a handful of big wireless phone operators for decades now. And the result has been a mobile phone system that is the direct opposite of the PC model. It severely limits consumer choice, stifles innovation, crushes entrepreneurship, and has made the U.S. the laughingstock of the mobile-technology world, just as the cellphone is morphing into a powerful hand-held computer.

Consumer choice could be better served through efforts of the OHA and the availability of the Android platform.

 

Figure 1. Phone vs. PC Architecture

Announcing Android and Open Handset Alliance

For quite some time, rumors have been swirling around what Google might be doing in the area of telecommunications. Mobile phones are a huge digital frontier so it makes sense for Google (who says their mission is to "organize the world's information") to take a leadership role. At Google's November 5^th teleconference, they once again changed the rules of the game by opening up the process and essentially inviting everyone in to take part in creating the future for mobile phones.

A number of companies that have played important, but largely invisible, roles in the mobile ecosystem are now moving to the forefront. For instance, HTC looks like it will be the first vendor to release one of these new phones in 2008. You may never have heard of HTC because their product is typically branded with the name of the mobile operator. (HTC makes my T-Mobile Wing phone, a fantastic device that is essentially a little computer you can talk to, but can't program. In the future, this same class of device running Android will be almost completely programmable and far more functional than what I have today.)

Representatives from Bloomberg, the Financial Times, and the Wall Street Journal (which ran a long front-page story the next day) all attended the November 5^th conference call introducing the OHA and Android. The top tier of the general news industry was there as well: the Washington Post, New York Times, Reuters, and USA Today asked questions and splashed their papers with stories. Technology publications like Computer World, PC Magazine, and Wireless News hooked onto the digital discussion.

Adding to the intrigue, some of the big players were noticeable by their absence: Nokia, Microsoft, Apple, and the BlackBerry team were not involved. Verizon and AT&T had no voice in the call. And the largest mobile operating system company around, Symbian, stayed away. Disruptive technologies often prove threatening to entrenched incumbents while providing enormous benefits to existing customers; it remains to be seen how the entrenched companies respond and whether they ultimately participate.

Some analysts quickly wrote off the initiative as "another" failed attempt at building a mobile operating system. A number of "open" alternatives exist—OpenMoko, Qtopia, or even Apple's iPhone environment. Plus, there is the Ubuntu Mobile and Embedded initiative and the Moblin organization. Why not use Maemo, MontaVista, or leverage work done in the Linux Phone Standards Forum?

Commercial competitors (Symbian and Windows Mobile come to mind) were not heaping praise on the effort. While some industry leaders dismissed the OHA as little more than a baseless-brochure pact, others were more optimistic. FCC Chairman Kevin Martin showed his support in a statement on November 6^th:

I was pleased to hear the announcement by the Open Handset Alliance of the plans to introduce an open platform for mobile devices. As I noted when we adopted open network rules for our upcoming spectrum auction, I continue to believe that more openness—at the network, device, or application level—helps foster innovation and enhances consumers' freedom and choice in purchasing wireless service.

Ideally, a free and open software platform could lower the cost of both the devices and the applications that run on them, thus making penetration into underdeveloped nations greater and bringing a new level of communications to people who currently lack it.

Quite a few questions lingered from that November 5^th conference call: What does the Android Platform SDK look like? How do you build applications with it? What standard technologies are used? How will Google and the Open Handset Alliance build developer support around their platform? Now we have some really good answers.

Figure 2. Open Handset Alliance ecosystem

What's in the SDK?

I was able to schedule some time to talk with Mike Cleron, Senior Staff Engineer at Google and Technical Lead for Android, along with Barry Schnitt from Google's Communications department. After working on this for more than a year in total secrecy, Mike was happy to discuss the architecture and application environment in detail. (You'll find some video of him being released today as well, where he is discussing the overall architecture of Android.) What follows are highlights from our conversation.

The Android SDK includes documentation, sample code, as well as all of the libraries and frameworks needed to build applications. Applications are written using Java. Thanks to a high-fidelity emulator that the SDK provides for Windows, Macintosh, and Linux, you can now develop applications on your personal computer of choice, run them, debug them, and fully test them in an environment that looks just like a mobile phone environment.

Consistent with the design goal of making the platform as open as possible, all Android code is being released under the Apache license. Anyone who wants to can extend, modify, or enhance the platform. (One adoption-accelerating consequence of using the Apache license is that handset manufacturers can write their own device-level drivers or make other customizations without being forced to release this intellectual property to competitors. In addition, third party developers can extend the object oriented user interface and add in their own suite of applications without running the risk of license infractions.)

Eventually, once the new Android-ready phones are available, you'll be able to easily load your application on the Android powered phone. The minimal requirements for these new phones will be an ARM model R9 running at 200 MHz. This requires no significant leap in present day processing power. Android appears to require a lower powered chip than what is believed to be running in the iPhone. Even the current model Wing is a class of phone that has adequate processing power to run Android.

One of the core differentiating features of Android is that it was truly designed from the ground up to be open, rather than attached to specific APIs. Thus, there is one general purpose API that can be modified, replaced, and heavily leveraged to talk with various applications. There is no specific API to talk with Gmail, Google Talk, or any Google offerings.

Application Development

You can run and fully debug Android applications on a standard PC desktop in an emulator, which faithfully reproduces how the application will perform on the actual hardware platform. Although some test mobile phones are running Android today, units are limited and functionality is essentially in prototype form.

Android applications have full access to the mobile platform: your applications can make phone calls, query for information over data links, put up alerts, beep and buzz, and do everything that SMS, or a browser can do. All of the software that is being released as Android was written with the same tools Google is releasing in the SDK.

Java is the main programming language. The wide array of libraries, documentation, and the robustness of the language along with its security strengths seem to make it a natural choice. Java's model of network-centric programming and dynamic, extensible programs that can be easily internationalized are all key ingredients in a global mobile solution.

Developers at Google are using a variety of IDEs, including IntelliJ, Eclipse, vi, and Emacs, with some testing done on NetBeans. The Android SDK ships with an Eclipse plugin to smoothly integrate with the emulator and support debugging with breakpoints, viewing source, and all the high-level debugging tools on the Eclipse platform. You can run and fully debug your applications in a desktop emulator.

I asked Mike if environments like JRuby could plug in here. (JRuby is simply the ability to write Ruby code in the NetBeans IDE and have it converted into Java bytecodes.) While it seems like that approach could work (for Jython as well), it hasn't been tested. Sun's CEO, Jonathan Schwatz wrote an encouraging note in his blog:

I'd…like Sun to be the first platform software company to commit to a complete developer environment around the platform, as we throw Sun's NetBeans developer platform for mobile devices behind the effort. We've obviously done a ton of work to support developers on all Java based platforms, and were pleased to add Google's Android to the list.

Perhaps Sun's efforts will expand Android's developer toolset.

The file I/O system is standard fare—data can be stored however you want in flat files or using the available implementation of SQLite. There is a database style API with rows and columns that makes it easy to save and retrieve data. None of the data storage restrictions of JavaScript, for instance, seem to apply. (It's possible an external micro storage device may be required for some data operations.)

To encourage openness across content providers, Google created a ContentProvider API that allows for data sharing across processes. The ContentProviderAPI allows applications to share content with any application that has appropriate permissions. So, for instance, it would be easy to do "mashups" with maps and other data sources, or to share personal information from an address book with other applications.

The development process is a standard one for Java developers: Java code is compiled into .JAR and .CLASS files. Google built a custom virtual machine to run these programs; it is called DALVIK (after one engineer's favorite location in Iceland.) The DALVIK VM is designed especially for Android to run on embedded systems and work well in low power situations; it's also tuned to the CPU attributes. The DALVIK VM creates a special file format (.DEX) that is created through build time post processing. The DEX files can be downloaded onto the mobile handsets and run.

Activity and Intent - Verb and Data

The GUI toolkit is generally referred to as the VIEW system. Like DALVIK, the VIEW system was specially designed and optimized by Google for running in embedded environments. Mike indicated that coding should be friendly and familiar to anyone who has worked with user interface toolkits before. (This section covers my understanding of some of the newest and most technical aspects of the platform. My understanding is based on a phone conversation with Mike. A clearer picture will quickly develop as we all get a chance to work with the SDK.)

Android takes the idea of an application and breaks it down into bite-sized components—each called an ACTIVITY. As an example, mail is broken down into main components like the following: show a list of email, show email message, create an outgoing message. This componentization should do well in an open source environment where developers can share smaller blocks of code and assemble them into more powerful applications from what is already available. Application-level components or services could be shared for common tasks, such as creating a mail message. It remains to be seen how sharing and distribution of these components evolve, but it's possible that a packaging process similar to Debian and Linux distributions might quickly take hold.

Developers use a general purpose data structure, called an INTENT to describe the object (DATA) the component is working on. A VERB, such as "show," and DATA described by an INTENT carry out the user's wishes and display what is requested. The overall application environment is object oriented, e.g., a VIEW is defined to inherit from a master VIEW class. Messages are passed between the objects to control behaviors. For example, when a user clicks on the HOME button, it doesn't launch software, but passes a message into the Android system which allows the developer an opportunity to change the location and behavior of HOME if you have a legitimate reason for doing so.

Any time you switch between screens displayed on the phone, your INTENTs are processed like URLs, allowing you to easily navigate from point A in an application to point B.

This is a new way of programming for many developers. Google realizes it will take some time for people to see and solve problems as components rather than monolithic programs.

Security

There are a couple of different layers of security. Java is well regarded for its security. It is already widely deployed in mobile phones and has a proven track record. In addition, Android applications operate on top of the Linux 2.6. kernel. Each application runs in a separate Linux ID space—insuring process, memory, and file protection as a natural benefit of using the Linux kernel. At a higher level, there is additional security involved in protecting resources, which presumably is under the control of the phone's owner.

Given proper access privileges, any application can dial the phone, access the camera, or any other resources available on the system. Google has written all their in-house and sample applications using the same framework that gets shipped to the world in the SDK so you can expect it to be robust. That said, if you download a tic-tac-toe game and it starts dialing phone numbers around the world, you'll want to check and make sure all the resource and security settings are properly set on your phone.

Developer Relations

The Android SDK that has just shipped is a preview. It is fully open source. It is not finished—it may be about half done, according to Mike—but it is definitely not considered a 1.0 product. They will be making documentation available in JavaDoc and HTML formats. The web browser included in the distribution is based upon the well-known WebKit.

This release is intended to invite feedback from the community. Google is looking to hear back on what they got right, what they got wrong, what they didn't get enough of, and what seems to be just right. Their goal with this preview SDK is feedback on the Android platform. Google will release updates "early and often" based upon the feedback they get.

To support this process, Google has launched a developer advocate program. That's a new team of people dedicated to working in support of the SDK and the developer community. They will run forums, maintain, and sustain blog entries on the topic of the SDK. In addition to releasing the Android SDK, Google simultaneously announced a $10 million Developer Challenge to spur innovation and encourage Android application development. All the details on this innovative program are available on Google's web site.

Eventually, the Android SDK will likely move into more of an open source model of development, perhaps similar to Linux, rather than controlled by Google as it now is. Certainly the team that Mike is on will continue to play a large role in charting the course for the platform, especially until a 1.0 release is achieved, in time for the first Android-powered phones to hit the market.

User Experience

Some of the early discussion around Android have promised an "Amazing" UI experience. I asked Mike what that means:

Our goal is to deliver a first class user experience—modern, simple, polished…what you'll see in the early access SDK is an interesting half-way point on the evolution of our UI…what you're seeing is a snapshot of the work in process … an equal number of revisions still need to be done."

You'll see a glimpse of this in the videos that will be released. Visual designers and interaction experts are hard at work on finishing things up for a 1.0 release. At present, performance is thought to be pretty good, so the user interface and the overall experience will get the majority of the technical investment in future builds.

The Key to Success? Developers

Chetan Sharma has advised a number of companies in the mobile ecosystem, including members of the Open Handset Alliance. The title to his forthcoming book, Mobile Advertising: Supercharge Your Brand in the Exploding Wireless Market, highlights the underlying economics driving this innovation. Sharma shared his observations:

I think overall, this is a very positive announcement. It means that Google is very serious about mobile. We have heard some rumblings in the past but no substantive initiatives. Now, it seems, Google is willing to take the fight to the carriers and to Microsoft (Nokia, RIM, and others).

Ultimately, the key success factor for Android is this: developers need distribution. Period. Developers can build the most innovative application on the weakest OS given a chance. Enhancements to OS and flexibility in application development are always good, but what really matters is distribution. How easy and expensive is it to get my application to a point where users can play and pay for it? Does Android solve that problem? Will developers have to go through some complicated process to get an application visible to the phone's owner and network subscriber?

Sharma also raised a practical concern echoed by a number of developers: "Will multiple implementations or adaptations of Android by different handset makers and service providers require that developers create multiple versions of the same application?" If that is the case, Sharma believes Android will just be a YAP (yet another platform) that developers have to painfully consider. Instead, Sharma sees real promise for Google and the Open Handset Alliance to advance the debate around "open access" and crack open the "walled gardens" that have kept phone users immobilized as captive customers in the past.

The fear of fragmentation is something that Google is thinking of too. Mike explained that there was nothing in the license (or underlying technology) to prevent vendors from making these kind of fragmenting changes. However, Mike is confident that consumer opinion will have a significant impact and encourage vendors not to create incompatibles.

One major benefit I see in using the Apache license is that handset manufacturers can take the Android platform and develop their own hardware level drivers before burning it onto devices. Apache licensing allows handset manufacturers to customize in a way that meets business needs without being forced to release incremental intellectual property created for proprietary hardware or drivers. It may not be ideal, but it is practical: this will accelerate openness and adoption among handset vendors who have very little to lose by offering at least compatibility with Android, but would never consider releasing their low-level device interfaces as open source software.

Conclusion

Ever since Clay Christensen's award winning 1997 book, The Innovator's Dilemma, the phrases "disruptive technology" and "disruptive innovation" have bounced around business circles like turbocharged pinballs at an arcade. Disruptive technology and disruptive innovation are typically good news for consumers who benefit from improvements in price and performance that often exceed consumer needs and expectations. However, incumbent businesses often find this unsettling—if not life threatening—when their existing business models are upended or made outright obsolete by the disruptions in the market and technology. What will happen when customers write their own programs? What will happen if customers and vendors agree to break out of the model of annual fees in exchange for an advertising funded model? As we get a handle on the range of options presented by the Android platform and related developments, there are many more business questions that remain unanswered.

Think of the changeover from horses to cars as a mode of transportation. What about the transition from components to integrated circuits? A disruption that has touched many of us is the changeover from film to digital cameras. Will mobile phones be next?

Fundamentally, Google and all the members of the OHA are trying to do two things: one is to grow their base of customers and revenue; two is to inspire and inject innovation into the mobile ecosystem. Long before Christensen's book appeared, Everett Rogers led many Stanford students through his own research appearing in his book titled Diffusion of Innovations. His book opens with the task that remains: "One reason why there is so much interest in the diffusion of innovations is because getting a new idea adopted, even when it has obvious advantages, is often very difficult." Google's calling. It's for you!

Resources

• Android Talks on YouTube
• Android Developer Blog
• Open Handset Alliance Web Site
• Android SDK Web Site

Brian DeLacey worked on mobile applications a decade ago—he wonders if and when he'll be able to install Android on his T-Mobile Wing sometime during 2008.