Running Android on x86

The Android-x86 project released the first release candidate for its version 4.0 on March 1. The release is based on the Ice Cream Sandwich (ICS) release of the Android source code, and introduces some important new features — such as hardware video acceleration for all three major GPU vendors, and a usable live USB image.

The Android-x86 project started off as an individual hobbyist effort, collecting patch sets against the upstream Android source that would allow developers to build the OS for specific hardware devices. As time went on, however, there was more and more consolidation and an ever-increasing pool of contributors. Thus, the project eventually grew into its current form, hosting Git repositories, producing ISO installers, and offering an email and IRC support community.

The project is entirely volunteer-driven and -governed, although AMD is credited as adding support for several of its platforms, and there are individual developers from Intel and other companies credited with contributions in the release notes. Interestingly enough, the very first x86 port of the Android Linux kernel was done by a Google employee. After that, outside developers first took up the challenge of getting the Android kernel to run on their own hardware, starting with the ASUS Eee PC, drawing from Moblin's efforts to get the kernel to boot and WiFi drivers to compile for the Eee, and on Canonical's Ubuntu Mobile Internet Device (MID) edition to get the GMA500 graphics chip working. Since roughly 2010, the project has steadily added new hardware platforms with each release.

The ice cream sandwich machine

The hardware supported by Android-x86 is still a subset of the Intel-compatible world. Intel has recently announced plans to bring Atom-based phones to the market in the latter half of 2012, which could boost interest in Android-x86 considerably, but for the moment the primary development targets are tablets and netbook-class portables. Each release is tested against specific devices; the current list supports ASUS Eee netbooks, the Dell Inspiron Mini Duo series, and several Lenovo offerings on the netbook side, plus the Viewsonic Viewpad, Samsung Q1U, and Viliv S5 tablets. All are Atom-based devices, and at the moment there are no 64-bit CPUs supported.

The project makes an effort to support as many hardware features as possible on the target platforms, including suspend/resume buttons, battery status, touch screens, cameras, Bluetooth, GPS, and accelerometers. However, most of these hardware features are already found in mobile phones and ARM-based tablets. Providing a usable experience on netbooks involves supporting external monitors, mice, and keyboards, not to mention external storage devices and a wider range of video chipsets.

ISOs of the 4.0-RC1 release are available for five hardware platforms, though more are certainly possible when the final 4.0 release is made. For comparison's sake, the 2.2 release from June 2011 (based on Android Froyo 2.2.2) supported seven separate platforms; subsequently there were test releases based on Gingerbread and Honeycomb, but neither was ever dubbed a stable release. In addition to the platform-specific ISO releases, there are nightly builds for "generic" PC hardware, and there are build instructions for the source itself. The ISO image weighs in at a modest 180 MB or so, depending on the device.

4.0-RC1 is based on the Android 4.0.3 source code release, using kernel 3.0.8 with kernel mode-setting (KMS). New to this release is hardware GPU acceleration for Radeon, NVIDIA, and Intel graphics, the addition of Chrome's V8 JavaScript engine (previous releases had used the JavaScript Compiler (JSC) instead), auto-mounting of hot-pluggable memory cards or USB storage, and experimental support for the Renderscript 3D rendering API. On the down side, wired Ethernet support is not working properly with the Android user space yet.

The ISO images themselves have also been beefed up in some noticeable ways. The filesystem is now compressed with Squashfs to save space, the live USB option runs in "hybrid" mode to permit using available flash space as persistent storage, and there is a text-based installer that supports the ext2, ext3, NTFS, and FAT32 filesystems.

Testing

I ran 4.0RC1 on a Lenovo S10 netbook; unscientifically I found it to be much faster than most Android phones I have used. That is no surprise from a hardware standpoint, of course, but even people who don't care for Android on mobile devices may be surprised at the resulting experience on a faster CPU with additional memory. All of the hardware worked, including WiFi, Bluetooth, and the touchscreen (which tends to confuse other distributions). Browsing, synchronizing email and other data, and all of the other essential tasks work smoothly. It is easy to tell that the OS was originally designed for a phone or tablet, though. In addition to referring to all disk space as "the SD card" there are places where Android-x86 is difficult to use without a touchscreen device.

For one thing, the project has added a software mouse cursor, and I had no trouble with my keyboard, but the unlock screen requires a swipe maneuver that is tricky to pull off on a touch pad. Second, although KMS correctly set the screen size to the S10's native resolution, that still results in large, Playskool-like menus and buttons. While they don't impede your ability to work, I cannot imagine liking it on a 24-inch desktop display where touch-sensitivity is not part of the arrangement.

However, neither of those nitpicks is an indictment of the quality of the software. Surprisingly enough, despite warnings to the contrary on the Android-x86 wiki, the new release has full access to the Android Market and can install most third-party apps as well. The tricky part is that Android-x86 will only work with pure Dalvik apps — almost all of the Android apps that use the Native Development Kit (NDK) are built for ARM. Unfortunately (or fortunately, depending on who you ask), the architecture difference also rules out Adobe Flash and applications that employ it.

However, as I discovered on the mailing list, there are beginning to be Android Market apps released specifically for the x86 architecture. Most are media players, which arguably have a greater need to optimize for speed, but their mere existence is intriguing.

More to come

Android-x86 does not have a formal roadmap, apart from the general convention of following the upstream Android source code releases. However, the site lists a few specific projects targeted for the near future. There are always new hardware platforms and chipsets to worry about, such as the AMD Brazos line, and unsupported features popular in netbook designs, such as the CrystalHD video decoder chip.

From the software side, Android-x86 does not yet have support for Android's native multitouch layer, although it is listed under "what we are working on now," and there is an effort by project maintainer Chih-Wei Huang to port the GStreamer multimedia framework to the OS. The GStreamer port would presumably replace Android's libstagefright as the multimedia abstraction library. In 2011, Collabora (home to many GStreamer developers) worked with ST Ericsson on an Android build of GStreamer, and that code remains available, although it seems highly unlikely to ever receive an official blessing from Google.

On March 11, developer Stefan Seidel sent a proposal to the Android-x86 mailing list with two suggestions for streamlining the development process itself. The first was an attempt to move from the separate-trees-for-each-target-device model currently being used to a unified tree. In addition to reducing duplication of effort and simplifying QA, he said, unifying the main tree would allow the project to produce a "base image" with each release that could be further customized by adding commercial or binary add-ons (such as the Google app suite) via an overlay filesystem like UnionFS or AuFS.

The second suggestion was partly an attempt to find a way around the difficulties posed by the Android sensor framework. The framework is what enables applications to access accelerometer or ambient-light sensor data. These sensors are far less common on Atom-based devices than in mobile phones, so many Android-x86 trees use a dummy library instead, which allows the user to simulate readings manually. Seidel proposes either overlaying real libraries over the dummy libraries for systems that support the sensors, or else adding a fail-over between the real and dummy libraries; in either case the end result would be that fewer hardware differences would exist to force developers to work on device-specific branches.

The others on the list seem supportive of the suggestions, and on board with the underlying goal of unifying the trees. In the resulting thread, many other suggestions for where the project should head next cropped up, including localization, FUSE support, and 64-bit support, which seems indicative of a motivated community.

What is not clear is whether or not there are very many people who use Android-x86 as a daily-use operating system. The question is interesting in light of how disruptive Android has been in the mobile phone market. If it takes off as a netbook offering, it would make for an unpredictable competitor for Google's other portable OS, ChromeOS, not to mention various other lightweight distributions.

This is not to say that the project needs 24/7 users in order to be valuable, of course. Evidently plenty of people do find it useful; the project blog even noted back in April 2011 that Amazon.com was using Android-x86 as the guest OS on EC2 in order to provide its application "test drive" service. Still, a test drive is by its very nature short. Users that run an OS day-in and day-out uncover different bugs and usability woes.

Should the traditional desktop Linux distributions be scared that Android will start eating into their market share? Probably not. But even as a volunteer-driven project with limited hardware targets, Android-x86 has produced a well-polished and usable release in very little time — one that comes with an pre-existing application ecosystem. Given that, the distributions would not be wise to ignore the possibility entirely.