I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

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.

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

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

1 comment

Register

Login

Forgot your password?

Your password has been sent to:

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