While Google today announced Google Chrome OS for netbooks and desktops, the company made clear on their official blog that Chrome OS is seperate from Android, which was conceived and designed for use in mobile devices. Recent announcements of lowcost netbook computers running Android, though, suggest that Android, which is overseen by the Open Handset Alliance, is becoming more than just a mobile phone platform.
It seems to me Android could easily jump from phone to netbooks to desktops as people get familiar with it. Is this finally the free Java "operating system" that has been haunting Microsoft for years? I figured it is time to take a serious look at what Android development is going to entail.
Architecture of Android
Think of Android as an operating system plus application framework and typical libraries and applications rather than a bare bones operating system. A Linux kernal handles the lowest level functions with hardware drivers for all the strange and marvelous hardware functions now appearing on mobile devices. Given the speed with which the Linux community ports to new hardware, you may see Android popping up in some amazing places.
I downloaded the Android 1.5r2 software developer's kit (SDK), over 170MB in a zipped file. This download includes a Plug-in for the Eclipse IDE but can be used without an IDE. Windows, Mac OS X (x86 only) and Linux operating systems are supported, Java 1.5 or 1.6 required. The documentation and examples are very extensive. Here is my list of what I think the most important points are:
- Java Version: All core applications are written in Java, but the JVM which executes them is a special version optimized for low power CPUs. The Android JVM, called Dalvik, uses a custom format for compiled class files. Each application gets its own JVM and Linux process to isolate it from other applications.
- Java Runtime: The class library is not exactly that of Sun's standard SDK library. The critical user interface toolkit and graphics classes are very different. I am expecting to see an explosion of multiple incompatible attempts to create extension libraries.
- Media and Sensors: As you would expect, given the emphasis modern phones place on graphics, all common static image, video and audio formats such as MP3 are supported for playback. The designers have tried to create a framework for present and future image recording and other sensor hardware. Current phone goodies such as GPS navigation, compass and accelerometer inputs are provided for. How this design holds up as hardware designers exercise their creativity remains to be seen.
- Network Communication: In addition to the normal java.net package of HTTP communication classes for reaching web services, Android provides classes to work with WiFi connectivity, and, of course, the wireless telephone network.
- Data Storage: Android rearranges the way developers will think about data storage, there is no common file system shared by all applications. Each application gets its own private data and can control what is exposed to other applications. There are four mechanisms, each with its own advantages and capabilities.
- Preferences: Android manages a lightweight set of key-value data pairs for each application.
- Files: Files stored locally or on removable media can be read and written with typical Java streams. Sharing file data between applications must be done indirectly through "Content Providers."
- Resource Files: Android supports the concept of "resource" files which are compiled into an application in an optimized format. Files used in your application such as images, strings and xml are compiled into fast loading binary formats.
- SQLite Database: SQLite is a very widely used open source SQL database engine. The Android toolkit provide all of the classes and methods needed to create and manipulate SQL tables.
Components and Messages: Android achieves communication between applications and components of an application by messages called "intents." An intent message is carried in a data holding object. Android is responsible for locating the targets of messages according the data type and the available components. This dynamic linking approach is required by the dynamic nature of the applications within Android.
Data and Content Providers: Content providers supply the only mechanism for sharing data across applications. Once your application has located a desired content type, for example a contacts list, access is similar to a simple database query. Content providers are created and managed by Android which enforces security rules. This arrangement eliminates many of the security holes afflicting desktop operating systems.
More about the SDK for Developers
Naturally, developing on a desktop for wildly different hardware is a little tricky. Every project you start in the SDK will be based on an emulator "Android Virtual Device." A completed Android application compiles code plus data and resources into a single Android package file, simplifying distribution. Although the standard Android distribution emphasizes the Eclipse IDE, there is also a NetBeans Plug-In project.
The way Android attempts to accommodate the vast expansion of sensor capabilities and user expectations of what a device should be able to do suggests a quantum jump in operating systems may be possible. The controlled isolation of individual applications should lead to much better security as well. The industry standard of a computer as consisting of a CPU, a monitor, a keyboard and a mouse could well be obsolete. Why not a new operating system vision too?
Google's starting page for Android
Online developer's guide, API reference, and developer's community blogs.
Open Handset Alliance home page.
This interview with Gosling touches on the relation of Android to standard Java.
Wikipedia entry on the Dalvik JVM
Home page for the open source SQLite package.
Home page for the open source WebKit project.