The Google Android Platform
Like Apple, Google is one of the upstart companies that jumped into the smartphone fray recently. In late 2007, the company launched its Android platform, a smartphone stack developed for the Open Handset Alliance, which is an association of 48 hardware, software, and telecommunications companies. In the fall of 2008, T-Mobile released the G1. Made by HTC, the G1 is the first smartphone using the Android platform. According to Admob, in January 2009 Android generated 3 percent of the smartphone network traffic a signficant jump considering the platform had only been on the market a few months. It will be interesting to see if this trend continues, especially as more Android-powered smartphones appear.
The Android platform is built upon Linux 2.6, whose pedigree can be traced back to its first source code release in 1991. Since then, Linux has evolved and its code heavily reviewed and extensively field-tested on just about everything, from embedded systems to mainframes. Linux therefore provides a solid foundation on which the Android platform is built. In addition, Android is distributed under the Apache license, which means all of its software components are free and the source code available.
Some of the features of the Android platform are:
- Built on Linux, a proven OS
- Multiple third-party applications can execute at the same time
- Applications can intercommunicate and share resources
- Open source, which holds the potential that developers will contribute applications and features to the platform
Android comes with a number of useful applications, such as an e-mail program (which makes use of Google's Gmail), a mapping program (using the company's Google Maps), and a browser that uses WebKit, not Google's Chrome web browser. However, Chrome happens to be based on Webkit.
Applications are written in Java, but Android is not Java ME, nor does it support such applications, for reasons that we'll see when we tour its software stack. Like most smartphones nowadays, Android can handle changes in screen orientation, and provides access to accelerometer data. Android applications are designed to operate concurrently, and on the G1, the platform is noted for its ability to both browse and manage multiple IM conversations. On the other hand, such heavy use of the smartphone's CPU shortens battery life significantly. Maybe Apple is on to something in limiting the number of applications that the platform can run.
Android as implemented on the G1 has some strange omissions, just like Apple's iPhone OS on the iPhone. For starters, Android doesn't offer a virtual keyboard. This problem is mitigated on the G1 with its built-in keyboard, and you can expect future Android releases to include an input management framework that support soft keyboards and other input options. Like the iPhone's version 2.2 OS, Android's Bluetooth stack lacks many useful profiles. Flash support is lacking as well. On the positive side, the Android APIs support a touch interface (and the G1 has a capacitive touch screen), but not any multi-touch gestures. The platform does currently support copy-and-paste, a feature the iPhone OS won't get until version 3.0. Note that Android's copy and paste only handles editeable text fields, and copying text from the web pages is the browser isn't allowed.. For starters, it doesn't offer a virtual keyboard. This problem is mitigated on the G1 with its built-in keyboard, but it does create problem for smartphone manufacturers who wish to release a touch-screen only device. Although the APIs support a touch interface (and the G1 has a capacitive touch screen), it lacks multi-touch gestures, which complicates web surfing and editing mail replies. Copy-and-paste is supported, but only for browser URLs, and not text in applications. Like the iPhone's OS, Android's Bluetooth stack lacks many useful profiles. Flash support is lacking as well.
Let's now examine the Android software stack (figure 4) to see how it implements the platform.
The Applications layer hosts all Android and third-party applications, and several or more third-party applications can execute simultaneously. However, as noted, doing so can shorten battery life.
Beneath the Applications layer is the Android Frameworks layer. This layer consists of Java classes that provide application functions such as window management, window content display, application messaging, and handling phone calls. Obviously the interface Android presents at this level uses the Java programming language, and because the source code is available, you can modify these classes to extend their capabilities or over override their behavior. Note that some of the lower levels in the stack present C++ interfaces.
Next on the software stack comes the Libraries and Runtime layer. The libraries implement 2D and 3D graphics support, along with multimedia content decoding. This layer has engines to support application features, such as a SQLite database engine and WebKit, which handles web content rendering.
Like Java ME, Android strives for hardware independence by using a bytecode interpreter to execute Android applications. However, it doesn't use Sun's JVM, but instead uses its own Dalvik Virtual Machine (DVM). The advantage to Android's use of a different bytecode interpreter is that the DVM was designed so that multiple instances of it can run, each in their own protected memory space, and each executing an application. While this approach offers stability and a robust environment for running multiple applications, it does so at the expense of compatibility with Java ME applications.
The lowest layer of the stack is the Linux kernel. It provides preemptive multitasking and system services such as threads, networking services, and process management. It handles all low-level drivers and manages the device's power. For a detailed description of Android system stack, see my earlier DDJ article, "The Android Mobile Phone Platform", September 2008.
Android Developer Tools
The programming language of choice for the Android platform is no surprise here Java, although you can use C++ if you're writing code that might reside in the other layers. With the Android Development Tools (ADT) plugin, you can use Eclipse to write and debug your applications. Other Java IDEs, such as IntelliJ, can be used. The Android SDK (now at version 1.1) is a free download.
Android's core Java libraries are derived from the Apache Harmony project, and are as compliant with J2SE as Google could can make them. Seasoned Java programmers will find the Android SDK an amalgam of Java SE and Java ME methods and classes, along with unique new ones that address the needs of mobile platforms. In short, while Java programming experience is valuable, you still have to master the SDK's new classes and methods. A manifest file serves a similar function as the Java ME one in that it describes the contents of the archive file and its entry point. However, the Android manifest also specifies the application's permissions, which are required for sharing resources, and the events that the application can handle. Additional XML files describe the application's UI elements, and how they are laid out on the screen. All of these enhancements mean that the Android program that you write aren't portable to other Java ME platforms, but this is also true of applications that you'd write using RIM's UI APIs.
The developer tools compile the Java code to generate Dalvik bytecode files, with an extension of .dex. These files, along with the manifest, graphics files, and XML files, are packaged into an .apk file that is similar to a Java JAR file. Fortunately, you can use the existing Java signing tools, Keytool and Jarsigner, to create keys and sign your Android application.
All Android applications must be signed or the platform won't execute them. While the SDK provides a developer key for use during code test, you must generate a private key to sign the application when it is ready for public distribution. The private key is required to identify the author of the application, and to establish relationships between applications so that they can share code or information. The certificate that you use to generate the private key does not require a signing authority, and you can use self-signed certificates for this purpose.
At the end of 2008, Google announced the availability of the Android Developer Phone 1, which is a HTC phone with the Android platform installed. This eliminates the purchase a G1 phone and a service contract from T-Mobile. The Developer Phone provides access to a shipping Android device without the cash outlay or contract contortions required when developing for the other platforms. The Developer Phone allows you access to a shipping Android device without the cash outlay or contract contortions required for the other platforms.
For application distribution, there's Google's Android Market, which was launched in October 2008. The only requirements are that the application must be signed, and you must pay a $25 USD application fee. Initially all applications distributed by the site had to be free, but in February the site began supporting priced applications. Google allows developers to take seventy percent of the proceeds. Unlike Apple, Google doesn't review the applications submitted to Android Market, although the user community can rate the application. This arrangement gives you a shot at writing an application that can truly enhance the platform. On the other hand, it's possible that you might pick up a malicious application before it is detected by the user community. Like most things in life, sometimes there isn't an ideal way to handle things, just practical compromises.
- Open source, open platform: if you hate the mail program, some third-party is writing a better one.
- If you're used to Java, you can start writing for the platform right away.
- Linux underpinnings permits reliable execution of multiple applications.
- Many of the mobile Java classes are specific to the platform, and tie applications that you write to it. However, this is also true of RIM's Blackberry classes, or Apple's Objective-C classes.
- Running multiple applications has its advantages, but can also shorten battery life significantly.