Analysis: Long odds for Google's ambitious Android

Mobile Java is ubiquitous, but woefully limited. Android wants to put Linux and Java desktop power in mobile developers' hands. Can Google remake mobile application development against the grain of powerful, entrenched competitors?

Virtually all mobile devices, from consumer cell phones to full-featured PDAs, are equipped with miniaturized Java virtual machines and classes that are standardized across devices and platforms. On Windows Mobile devices, Java is a third-party guest, but sufficiently well implemented that Midlets, applications built to the MIDP (mobile information device profile), run just about anywhere. Even with the aid of standards, examples, and documentation, it must be said that developing mobile Java applications is a chore, and developers must often rely on platform-specific system software for user interfaces and for access to phone and PDA features. Because of this, mobile application developers tend to skip Java and code directly to their target platform's native languages and libraries. Of mobile devices, only BlackBerry treats Java as its native language, and even there, platform-specific extensions, some of which are locked away by the vendor, are required.

Google, whose future depends on a pervasive cross-platform mobile applications model -- Google Maps and Talk are examples of applications that could not be done as so-called "Web 2.0" apps -- has an obvious need to create a cross-platform mobile SDK for its own use. Some mobile device manufacturers and wireless operators have realized the benefits that gathering around a cross-device, cross-vendor, cross-operator mobile platform would bring to their customers and bottom lines. It's no great leap of logic that if Google requires a standard platform to support its mobile applications, manufacturers and carriers have a strong financial incentive to get in line. To this end, Google created the Open Handset Alliance, and its first tangible product is Google's mobile application platform, Android.


Android is not a set of extensions to existing phone software. It seeks to supplant, or at least provide an alternative to, disparate mobile platforms such as Windows Mobile and Symbian. Android has the ambitious mission of creating a total mobile device software platform, from the chip level to the user GUI, based on Linux 2.6 and implementing a custom Java virtual machine, a WebKit-based browser, SQL database, and full application access to device hardware. It's every mobile developer's dream, but right now, Android is a set of Java classes, some rough-hewn tools, and a device emulator, the last of these giving Android a shot at pull from end users.

See today's Strategic Developer for a "Hello, World!" example in Android.

Android's mission is so astonishingly broad that it will likely take years before it is realized in a handset. Mobile developers have been waiting for eons for a unified platform, and if Android finds form in a physical device, it could turn mobile software on its ear. Google doesn't want developers to wait for hardware; it has offered a $10 million bounty for applications that make best use of the Android platform. Then again, while $10 million is a tasty sum for contestants, it's play money for Google.

The bounty isn't just to get developers excited. It's to spur Open Handset Alliance members to turn intentions and beneficial PR into reality. Google hopes that if developers and users get hooked on a sampling of knockout Android applications, Alliance members will hurry to turn that buzz into revenue. Without the promise of riches to spur the Alliance into fast action, the Open Handset Alliance will plod along at the sorry pace of the mobile industry as a whole, where progress is measured in decades.

In this early SDK, Android does begin to address one of the greatest pain points for cross-platform mobile application developers, that being graphical user interfaces. Like the rest of Android, its UI support is in an early stage, with a limited set of widgets (GUI objects like buttons and text editor windows), but it offers the option of using Android Java UI classes or an XML representation for application graphical interfaces. The XML UI option is an enticing one, not only because it promises to provide a developer- (and user-) extensible means for drawing and interacting with cross-platform mobile forms, but because over time, 2D widget sets and layouts will become more powerful and attractive without requiring application changes. Developers will make extensive use of Android's ability to give an application ownership of the entire display for 2D graphical applications, so what the Android GUI doesn't provide, developers can create themselves. Android also wraps OpenGL ES 1.0 for 3D graphics, and has inherent support for all relevant digital media types.

An essential aspect of Android is its reliance on the Google-built Dalvik Java Virtual Machine, a component that Google is likely to hold proprietary, a fact that may rub some developers the wrong way. Dalvik is necessary because while mobile Java is covered by standards, Java access to device hardware is, shall we say, at manufacturers' discretion. With Linux running device hardware and the Dalvik JVM wired tightly into Linux, applications' ability to drive the device on users' behalf, and with excellent performance, is potentially unlimited, but the operative word there is "potentially."

The Android platform's reach will be determined by its presence in devices and support on wireless carriers' networks. The list of Open Handset Alliance members includes major players Motorola and HTC, but 800-pound gorillas Nokia, Research in Motion, and Microsoft are absent, and up-and-comer Apple doesn't do alliances. While NTT DoCoMo, T-Mobile, Sprint, and China Mobile Communications Corporation offer the potential for worldwide network coverage, AT&T is not on the roster of Alliance members. Google managed to assemble a quorum of semiconductor manufacturers including Texas Instruments, Intel, Marvell, Qualcomm, SiRF Technology, and Broadcom. So if Android takes off, it won't be hard to get for those customers who set out to find it, or whose operators have a monopoly hold on their market, but many customers are unlikely to come across Android by serendipity, as they do with mobile Java now. It bears pointing out that while the world of technology is planted thick with alliances and consortia, they can amount to little more than bet-hedging; if some wild idea happens to take off, it's wise not to be last in line.

It will take guts, figuratively and literally, to get Android off the ground. Some device manufacturer will open its goods to Google, Aplix, and Wind River, and some wireless operator will have to open its network to that device. The buzz around iPhone gives Google some hope of convincing Alliance members that some millions of end users will buy into desktop-grade handsets. At least Motorola has floated a couple of trial balloons in the form of Linux handsets, although these are not Android phones. To succeed, Android will have to battle it out with Microsoft, Nokia, and Adobe, all of which have well-established platforms or frameworks and familiar, if not consistently welcoming, developer tools.

Google is betting, although not too heavily, that it has the clout to push the mobile industry into a standard that aligns with Google's application platform desires. Google's aspirations are admirable, but the likelihood of Android succeeding as a full metal-to-screen platform, while parallel efforts are being worked by vendors with traction and experience, is fairly slim. Perhaps Google will manage to move the goalposts a bit, or light a fire under the sleepy mobile industry, and if Android achieves either of these ends, it should be praised as a success.

Copyright © 2007 IDG Communications, Inc.