Introducing the Android Computing Platform
-
font size
decrease font size
increase font size
We are also expecting a surge in mobile programming in the IT industry as more and more IT applications start to offer mobile counterparts. To help you profit from this trend, we’llshow you how to use Java to write programs for devices that run on Google’s Android Platform (http://code.google.com/android/), an open source platform for mobile development. We are excited about Android because it is an advanced platform that introduces a number of new paradigms in framework design. In this chapter, we’ll provide an overview of Android and itsSDK, show you how to take advantage of Android source code, and highlight the benefits of programming for the Android Platform.
The fact that hitherto dedicated devices such as mobile phones can now count them-selves among other venerable general-computing platforms is great news for programmers(see Figure 1-1). This new trend makes mobile devices accessible through general-purpose com-puting languages and therefore increases the range and market share for mobile applications.
The Android Platform fully embraces this idea of general-purpose computing for hand-held devices. It is indeed a comprehensive platform that features a Linux-based operatingsystem stack for managing devices, memory, and processes. Android’s libraries cover tele-phony, video, graphics, UI programming, and every other aspect of the physical device.
The Android Platform, although built for mobile devices, exhibits the characteristics of afull-featured desktop framework. Google makes this framework available to Java programmersthrough a software development kit called the Android SDK. When you are working with theAndroid SDK, you rarely feel that you are writing to a mobile device because you have access tomost of the class libraries that you use on a desktop or a server—including a relational database.
The Android SDK supports most of Java Platform, Standard Edition (Java SE) except for theAbstract Window Toolkit (AWT) and Swing. In place of the AWT and Swing, the Android SDKhas its own extensive modern UI framework. Because you’re programming your applications inJava, you might expect to need a Java Virtual Machine (JVM) that is responsible for interpretingthe runtime Java bytecode. A JVM typically provides necessary optimization to help Java reachperformance levels comparable to compiled languages such as C and C++. Android offers itsown optimized JVM to run the compiled Java class files in order to counter the handheld devicelimitations such as memory, processor speed, and power. This virtual machine is called theDalvik VM, which we’ll explore in the section “Delving Into the Dalvik VM.”
The familiarity and simplicity of the Java programming language coupled with Android’sextensive class library makes Android a compelling platform to write programs for. Figure 1-2 provides an overview of the Android software stack. (We’ll provide further details in the sec-tion “Understanding the Android Software Stack.”)
History of Android
Now that we’ve provided a brief introduction to the Android Platform, we’ll describe how it appeared on the mobile-development scene. Mobile phones use a variety of operating systems such as Symbian OS, Microsoft’s Windows Mobile, Mobile Linux, iPhone OS (based on Mac OS X), and many other proprietary OSs. Supporting standards and publishing APIs would greatly encourage widespread, low-cost development of mobile applications, but none of these OSs has taken a clear lead in doing so. Then Google entered the space with its Android Platform, promising openness, affordability, open source code, and a high-end development framework.
Google acquired the startup company Android Inc. in 2005 to start the development of the Android Platform (see Figure 1-3). The key players at Android Inc. included Andy Rubin, Rich Miner, Nick Sears, and Chris White.
In late 2007, a group of industry leaders came together around the Android Platform to form the Open Handset Alliance (http://www.openhandsetalliance.com). Some of the alli-ance’s prominent members include
Part of the alliance’s goal is to innovate rapidly and respond better to consumer needs, and its first key outcome was the Android Platform. Android was designed to serve the needs of mobile operators, handset manufacturers, and application developers. The members have committed to release significant intellectual property through the open source Apache License, Version 2.0.
The Android SDK was first issued as an “early look” release in November 2007. In Septem-ber 2008, T-Mobile announced the availability of the T-Mobile G1, the first smartphone based on the Android Platform. A few days after that, Google announced the availability of Android SDK Release Candidate 1.0. In October 2008, Google made the source code of the Android Platform available under Apache’s open source license.
When Android was released, one of its key architectural goals was to allow applications to interact with one another and reuse components from one another. This reuse not only applies to services, but also to data and UI. As a result, the Android Platform has a number of architectural features that keep this openness a reality. We’ll delve into some of these features in Chapter 3.
Android has also attracted an early following because of its fully developed features to exploit the cloud-computing model offered by web resources and to enhance that experience with local data stores on the handset itself. Android’s support for a relational database on the handset also played a part in early adoption.
In late 2008 Google released a handheld device called Android Dev Phone 1 that is capable of running Android applications without being tied to any cell phone provider network. The goal of this device (approximate cost $400.00) is to allow developers to experiment with a real device that can run the Android OS with out any contracts. At around the same time, Google also released a bug fix version 1.1 of the OS that is solely based on 1.0. In releases 1.0 and 1.1 Android did not support soft keyboards, requiring the devices to carry physical keys. Android fixed this issue by releasing the 1.5 SDK in April of 2009, along with a number of other features, such as advanced media-recording capabilities, widgets, and live folders. The last two chapters of this book are dedicated to exploring the features from this 1.5 SDK
Delving into the Dalvik VM
Google has spent a lot of time thinking about optimizing designs for low-powered handhelddevices. Handheld devices lag behind their desktop counterparts in memory and speed by eight to ten years. They also have limited power for computation; a handheld device’s total RAM might be as little as 64MB, and its available space for applications might be as little as 20MB.
The performance requirements on handsets are severe as a result, requiring handset designers to optimize everything. If you look at the list of packages in Android, you’ll see that they are full-featured and extensive in number. According to Google, these system libraries might use as much as 10MB, even with their optimized JVM.
These issues led Google to revisit the standard JVM implementation in many respects.(The key figure in Google’s implementation of this JVM is Dan Bornstein, who wrote the Dalvik VM and named it after a town in Iceland.) First, the Dalvik VM takes the generated Java class files and combines them into one or more Dalvik Executable (.dex) files. It reuses duplicate information from multiple class files, effectively reducing the space requirement (uncom- pressed) by half from a traditional .jar file. For example, the .dex file of the web-browser app in Android is about 200K, whereas the equivalent uncompressed.jar version is about 500K. The .dex file of the alarm-clock app is about 50K, and roughly twice that size in its .jar version.
Second, Google has fine-tuned the garbage collection in the Dalvik VM, but it has cho-sen to omit a just-in-time (JIT) compiler, in this release at least. The company can justify this choice because many of Android’s core libraries, including the graphics libraries, are imple-mented in C and C++. For example, the Java graphics APIs are actually thin wrapper classes around the native code using the Java Native Interface (JNI). Similarly, Android provides an optimized C-based native library to access the SQLite database, but this library is encapsulated in a higher-level Java API. Because most of the core code is in C and C++, Google reasoned that the impact of JIT compilation would not be significant.
Finally, the Dalvik VM uses a different kind of assembly-code generation, in which it uses registers as the primary units of data storage instead of the stack. Google is hoping to accom-plish 30 percent fewer instructions as a result.
We should point out that the final executable code in Android, as a result of the Dalvik VM, is based not on Java bytecode but on .dex files instead. This means you cannot directly execute Java bytecode; you have to start with Java class files and then convert them to linkable .dex files.
This extreme performance paranoia extends into the rest of the Android SDK. For exam-ple, the Android SDK uses XML extensively to define UI layouts. However, all of this XML is compiled to binary files before these binary files become resident on the devices. Android provides special mechanisms to use this XML data.
While we are on the subject of Android’s design considerations, we should answer this question: How would one compare and contrast Android to Java Platform, Micro Edition (Java ME)?
Comparing Android and Java ME
As you have seen so far in this chapter, Android has taken a dedicated and focused approach to its mobile-platform efforts that goes beyond a simple JVM-based solution. The Android Plat-form comes with everything you need in a single package: the OS, device drivers, core libraries,the JNI, the optimized Dalvik VM, and the Java development environment. Developers can be assured that when they develop new applications, all key libraries will be available on the device.
Let us offer a brief overview of Java ME before comparing the two approaches. Figure 1-4 shows the availability of Java for various computing configurations. Java Platform, Standard Edition (Java SE) is suitable for desktop and workstation configurations. Java Platform, Enter-prise Edition (Java EE) is designed for server configurations.
Java Platform, Micro Edition (Java ME) is an edition of Java that is pared down for smaller devices. Furthermore, two configuration sets are available for Java ME. The first configura- tion is called the Connected Device Configuration (CDC). Java ME for CDC involves a pared down version of Java SE with fewer packages, fewer classes within those packages, and even
fewer fields and methods within those classes. For appliances and devices that are further con-strained, Java defines a configuration called Connected Limited Device Configuration (CLDC).The available APIs for various Java configurations are contrasted in Figure 1-5.
Any optional packages that are installed on top of the base CDC and CLDC APIs are treated as “profiles” that are standardized using the JSR process. Each defined profile makes an additional set of APIs available to the developer.
The CLDC Java platform is hosted on a specialized and much reduced JVM called the K Virtual Machine (KVM), which is capable of running on devices whose memory is as low as 128K. (The “K” in “KVM” stands for “kilobytes.”) CLDC can run additional APIs under MIDP (Mobile Information Device Profile) 2.0. This API includes a number of packages under javax.microedition.*. The key packages are MIDlets (simple applications), a UI package called LCDUI, gaming, and media.
The CDC configuration APIs include the java.awt API, the java.net API, and more secu-rity APIs in addition to the CLDC configuration APIs. The additional profiles available on top of CDC make the javax.microedition.xlet API available to application programmers (Xlets represent applications in the CDC configuration). On top of a CDC configuration you’ll find about ten more optional packages that you can run, including Bluetooth, Media API, OpenGL for Embedded Systems (OpenGL ES), Java API for XML Processing (JAXP), JAXP-RPC, Java 2D, Swing, Java Remote Method Invocation (Java RMI), and Java Database Connectivity {JDBC). Overall the Java ME specification includes more than 20 JSRs. It is also expected that JavaFX (http://javafx.com) will play an increasing role in the mobile space for Java.
Now that you have a background on Java ME, look at how it compares to Android
Multiple device configurations: Java ME addresses two classes of micro devices and offers standardized and distinct solutions for each. Android, on the other hand, applies to just one model. It won’t run on low-end devices unless or until the configurations of those devices improve.
Ease of understanding: Because Android is geared toward only one device model, it’s easier to understand than Java ME. Java ME has multiple UI models for each configura-tion, depending on the features supported by the device: MIDlets, Xlets, the AWT, and Swing. The JSRs for each Java ME specification are harder to follow; they take longer to mature; and finding implementations for them can be difficult.
Responsiveness: The Dalvik VM is more optimized and more responsive compared to the standard JVM supported on a similarly configured device. You can compare the Dalvik VM to the KVM, but the KVM addresses a lower-level device with much less memory
Java compatibility: Because of the Dalvik VM, Android runs .dex bytecode instead of Java bytecode. This should not be a major concern as long as Java is compiled to stan-dard Java class files. Only runtime interpretation of Java bytecode is not possible.
Adoption: There is widespread support for Java ME on mobile devices because most mobile phones support it. But the uniformity, cost, and ease of development in Android are compelling reasons for Java developers to program for it.
Java SE support: Compared to the support for Java SE in CDC, the Android support for Java SE is a bit more complete, except for the AWT and Swing. As we mentioned earlier,Android has its own UI approach instead. In fact, Android’s declarative UI resembles the JavaFX approach.
Understanding the Android Software Stack
So far we’ve covered Android’s history and its optimization features including the Dalvik VM,and we’ve hinted at the Java programming stack available. In this section, we would like to cover the development aspect of Android. Figure 1-6 is a good place to start this discussion.
At the core of the Android Platform is Linux kernel version 2.6, responsible for device driv-ers, resource access, power management, and other OS duties. The supplied device drivers include Display, Camera, Keypad, WiFi, Flash Memory, Audio, and IPC (interprocess com-munication). Although the core is Linux, the majority—if not all—of the applications on an Android device such as the T-Mobile G1 are developed in Java and run through the Dalvik VM.
Sitting at the next level, on top of the kernel, are a number of C/C++ libraries such as OpenGL, WebKit, FreeType, Secure Sockets Layer (SSL), the C runtime library (libc), SQLite,and Media. The system C library based on Berkeley Software Distribution (BSD) is tuned (to roughly half its original size) for embedded Linux-based devices. The media libraries are based on PacketVideo’s (http://www.packetvideo.com/) OpenCORE. These libraries are responsible for recording and playback of audio and video formats. A library called Surface Manager con-trols access to the display system and supports 2D and 3D.
The WebKit library is responsible for browser support; it is the same library that supports Google Chrome and Apple Inc.’s Safari. The FreeType library is responsible for font support.SQLite (http://www.sqlite.org/) is a relational database that is available on the device itself.SQLite is also an independent open source effort for relational databases and not directly tied to Android. You can acquire and use tools meant for SQLite for Android databases as well.
Most of the application framework accesses these core libraries through the Dalvik VM, the gateway to the Android Platform. As we indicated in the previous sections, Dalvik is opti-mized to run multiple instances of VMs. As Java applications access these core libraries, each application gets its own VM instance. The Dalvik VM is backward-compatible with Java SE Development Kit (JDK) 5.0 but optimized for the Android Platform. However, some features of the Java experience might differ because the version of Java SE on Android is a subset of the full platform.
The Android Java API’s main libraries include telephony, resources, locations, UI, con-tent providers (data), and package managers (installation, security, and so on). Programmers develop end-user applications on top of this Java API. Some examples of end-user applications on the device include Home, Contacts, Phone, Browser, and so on.
Android also supports a custom Google 2D graphics library called Skia, which is written in C and C++. Skia also forms the core of the Google Chrome browser. The 3D APIs in Android, however, are based on an implementation of OpenGL ES from the Khronos group (http://www.khronos.org). OpenGL ES contains subsets of OpenGL that are targeted toward embedded systems.
From a media perspective, the Android Platform supports the most common formats for audio, video, and images. From a wireless perspective, Android has APIs to support Bluetooth,EDGE, 3G, WiFi, and Global System for Mobile Communication (GSM) telephony, depending on the hardware.
