Let us look at how Android arrived on the Mobile OS landscape. 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), Moblin (from Intel), and many other proprietary OSs. So far no single OS has become the de facto standard. The available APIs and environments for developing mobile applications are too restrictive and seem to fall behind when compared to desktop frameworks. This is where Google comes in. The Android platform promised 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 . 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 alliance’s prominent members are as follows:
�� Sprint Nextel
�� T-Mobile
�� Motorola
�� Samsung
�� Sony Ericsson
�� Toshiba
�� Vodafone
�� Intel
�� Texas Instruments
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.
Delving into the Dalvik VM:
As part of Android, Google has spent a lot of time thinking about optimizing designs for low-powered handheld devices. 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. According to Google, these system libraries might use as much as 10 to 20MB, even with their optimized JVM.
NOTE: The T-Mobile G1 phone, released in late 2008, comes with 192MB of RAM, a 1GB SD card, and a 528 MHz Qualcomm MSM7201A processor. Motorola Droid, released in late 2009, comes with 256MB of RAM, a 16GB microSD card, and a 550 MHz Arm Cortex Processor. Compare that to the lowest-priced Dell laptop, which comes with a 2.1 GHz dual-core processor and 4GB of RAM.
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. According to Google, these system libraries might use as much as 10 to 20MB, 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—Dalvik is the name of 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 (uncompressed) 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 chosen to omit a just-in-time (JIT) compiler, in early releases. The 2.0 codebase seem to have the necessary sources for a JIT compiler but is not enabled in the final release. It is anticipated that it will be part of future releases. The company can justify this choice because many of Android’s core libraries, including the graphics libraries, are
implemented 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 accomplish 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 byte code but on .dex files instead. This means you cannot directly execute Java byte code; you have to start with Java class files and then convert them to linkable .dex files. This performance paranoia extends into the rest of the Android SDK. For example, 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 already seen, Android has taken a comprehensive, dedicated, and focused approach to its mobile platform efforts that go beyond a simple JVM-based solution. The Android Platform comes with everything you need in a single package: the OS, device drivers, core libraries, JNI, 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.
This comprehensive approach differs from other mobile efforts such as Java ME. Let us offer a brief overview of Java ME before comparing the two approaches. Figure shows the availability of Java for various computing configurations. Java Platform, Standard Edition (Java SE) is suitable for desktop and workstation configurations. Java Platform, Enterprise 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. Two configuration sets are available for Java ME. The first configuration is called the Connected Device Configuration (CDC). Java ME for CDC involves a pareddown 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 constrained, Java defines a configuration called Connected Limited Device Configuration (CLDC).
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. CAUTION: Both CLDC and CDC might support some Java APIs outside Java SE, and their
classes might not start with the java.* namespace. As a consequence, if you have a Java program that runs on your desktop, there are no guarantees that it will run on devices supporting only micro editions.
The CLDC Java platform is hosted on a specialized and greatly 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 security 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), Java Database Connectivity (JDBC), and Java API. 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.
NOTE: JavaFX is a new user interface effort from Sun to dramatically improve applet-like functionality in browsers. It offers a declarative UI programming model that is also friendlier to designers.
