Tip

Five drawbacks to running Android as a desktop OS

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

    Requires Free Membership to View

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).

This was first published in September 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Expert Discussion

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.