Manage Learn to apply best practices and optimize your operations.

Five drawbacks to running Android as a desktop OS

If you're an Android lover, you can run it as a desktop OS inside a VM -- just remember it won't run like Windows.

You may hear arguments that the Android OS is becoming the new Windows -- that it's becoming the commodity operating...

system everyone's running on a whole spectrum of hardware. We're not yet at the point of seeing desktops shipping with Android, but that might not be too far off, so it's a good time to learn about Android on a desktop system.

It's entirely possible to experience Android in a desktop environment without having to install it on a desktop, notebook or tablet. As with any other OS running on hardware where virtualization software is available, you can run Android in a virtual machine (VM). Still, it may not include the complete range of features available in a full hardware deployment.

Most people use Android on a tablet or phone, the vast majority of which use non-Intel processors that aren't supported by conventional VM technology. The HTC One sitting on the desk next to me, for instance, uses the Qualcomm Snapdragon 600 ARMv7 system-on-chip processor. Not much chance of emulating that in VMware Workstation or Oracle VirtualBox!

Luckily, Android does exist in builds for different processors, since the source code for the OS is available -- also thanks to an intrepid community of hobbyists and experimenters who've done the legwork to port the OS to other platforms. The x86 port is the easiest one to run in a VM on commodity desktop PC hardware.

One such build is available from the Android-x86 Project and can be downloaded as an ISO image. The project maintains different ISO images for different types of client hardware: ASUS, IBM, Dell and so on. For the sake of testing, I obtained the Android-x86 4.3 development build, which runs pretty well in a VM and also provides mouse and pointer support.

When you compare Android to desktop Linux or Windows, there are five factors worth keeping in mind if you're running it in a VM:

Android is optimized for touch devices. Most desktop VMs use desktop interface hardware -- mice and keyboards -- as the standard devices to emulate. You might need to do a little extra configuration to ensure that touch devices are properly supported in the VM.

Over time, this ought to become a nonissue. VMware Workstation 10 has "pass-through" support for touch devices as well as such tablet devices as accelerometers. That means you can run Workstation on a machine equipped with such things and have support for them passed to the host OS (in this case, Android).

Guest additions do not exist for Android. Desktop VM software provides a "guest additions" package to be installed in supported guest OSes (Linux and Windows, typically). Once installed, it allows closer integration between the guest and the host -- for instance, by allowing clipboard sharing or providing accelerated graphics. No such guest additions package exists for Android -- at least, not yet. Consequently, integration between Android and the host OS will be limited.

Third-party builds of Android may be minimal. Don't expect to run a version of Android that's tricked out with the same add-ons as what's in your phones and tablets. The x86-compiled builds of Android generally eschew anything that can't be distributed freely, so you won't see anything other than the most basic skins or bare-bones collections of preloaded apps. Some such builds are compiled for specific manufacturers' devices, but the scope of customization is usually limited to having certain device drivers.

Watch out for differences between Android and desktop OSes. One key difference that fairly hit me in the face was the way power events are handled.

More on Android

Data and device encryption for Android

Comparing iOS and Android in the enterprise

Quiz: Android device security

With a desktop OS, if you send an ACPI (Advanced Configuration and Power Interface) shutdown event -- generally, a power-button-press action -- to the guest OS, most guests take that as a sign to turn off. Android interprets this event as a sign to wake up or go to sleep. So, after idling for a few minutes, my copy of Android in a VM went to sleep and displayed a black screen, which I misinterpreted as a screen saver. Sending keystrokes or mouse actions didn't do anything. It turned out Android had gone into low-power mode and needed a power-button press to wake up again.

Not everything works as intended. Your mileage will vary widely depending on what build of Android you're using, what the capabilities of your VM are, and what hardware is being virtualized or provided to the host via pass-through. One VM installation of Android on my test setup wasn't able to run YouTube, for instance, possibly because of limitations in the emulated video hardware (e.g., no accelerated video decoding available).

Dig Deeper on Virtual desktop management