Domo Arigato Mr Androidato—An Introduction to the New Google Mobile Linux Framework, Android

The third layer in the Android framework consists of a set of shared C/C++ libraries, core Java libraries and the Dalvik virtual machine. The current set of libraries available in the Android SDK includes a BSD-derived implementation of libc optimized for embedded Linux devices, media libraries based on PacketVideo's OpenCORE, a display subsystem and 2-D/3-D management library called surface manager, LibWebCore, the SGL 2-D graphics engine, 3-D libraries associated with the OpenGL ES 1.0 API, FreeType and SQLite.

In addition to these libraries are the assorted core Google Java libraries. Some people have questioned the Android implementation of Java as proprietary, although others claim the implementation is a necessity for Google to optimize the Android framework. The important thing to remember is that the Google Java libraries provide only a subset of what the Sun Java libraries provide. The remaining portion of this layer is Dalvik. Dalvik is a memory-optimized Java Virtual Machine (JVM) created by Google to run optimized .dex bytecode. In addition to the Google Java libraries, Dalvik and the associated bytecode compiler dx remain a potential source of contention in the Free and Open-Source Software world. Google claims the source will be available soon, but remains mum about why it decided not to pursue these changes through Sun's open-source Java efforts.

The layer closest to the physical hardware in the Android framework is the Linux kernel. Android is scheduled to ship with version 2.6.x, and it will rely on Linux to manage a variety of services, such as security, memory management, process management, networking and drivers for a variety of devices.

If you are interested in working with the Android SDK, you can do so through Eclipse or through other development environments or IDEs. If you want to use the Eclipse IDE, you need to have version 3.2 or 3.3 installed, along with the Eclipse JDT Plugin, as well as version 5 or 6 of the Java Development Kit (JDK). You also may want to install the Android Development Tools (ADT) Plugin through the Software Updates menu using the following link: https://dl-ssl.google.com/android/eclipse. The ADT Plugin automates a lot of what you would have to do manually in order to develop Android applications, and it is recommended if you are new to Java development or if you are generally lazy like most programmers.

After you are done setting up your environment, you need to add the most important piece, the Android SDK. You can find the most recent version of the SDK at code.google.com/android/download.html. After downloading the SDK, it is recommended you verify the md5 checksum before unzipping the contents. Once you have verified the contents, you then need to unzip the contents to a location of your choice and add the corresponding path to the Android menu within your Eclipse preferences menu.

Figure 4. The default menu for Android shown through the emulator. You can navigate the menu by clicking the buttons with your mouse or selecting them with your keypad.

If you do not want to use Eclipse, you still need JDK 5 or 6 and Apache Ant 1.6.5 or later, in addition to the Android SDK. I leave it up to you to perform the necessary steps associated with sourcing the SDK components into the proper path if you choose not to use Eclipse. If you run into problems, it is important to note that the GNU compiler for Java (GCJ) is not supported, and that if you have JDK 1.4 installed, you will not be able to use the Android framework. If you have questions about installing the Android SDK and/or configuring your environment, more in-depth information is available on the Android Web site.

One of the best things about the Android SDK is how easy it is to get up and running. Using my existing Eclipse Europa environment, I was able to start work on my first application only a few minutes after downloading all of the components. It literally took me a few mouse clicks and keystrokes to get the equivalent of a “Hello, world!” application running in the Android emulator, and only a few more minutes to get a Notepad application running. The next best thing about Android is that it is completely focused on application development and not on peripheral requirements, such as kernel compilation and installation. If you want to be completely focused on mobile Java application development, Android might be the mobile Linux framework for you. In short, Google has painstakingly taken the time to provide a great abstraction layer for developing mobile Linux applications, and it has provided a path to existing Java application programmers to create Google-enabled and OHA-supported applications.

Despite all these wonderful things, I must confess that I still felt slightly unsatisfied with Android. On the one hand, I was very happy to be able to start working on application development so quickly, but on the other hand, I felt like, that's it? Maybe it's because I was working with the beta version of the SDK and not all of the components have been released yet, but for some reason, I felt more like a kid snapping Legos together than a developer creating an application stack on which to run my new application. So, if you are like me and want control over your entire stack, I still recommend sticking with a more transparent and flexible approach like the OpenMoko framework. Just remember, that like all other free and open-source software projects, the choice is yours.