Android, the phone and tablet operating system, is currently very popular, so many applications are written for Android only. Still there are situations where it makes sense to run such applications on a desktop PC. This is what we want to do here.

For reasons explained in the FAQ below, running Android in an emulator is the most straightforward way. One of the most often used Open Source emulator is Qemu, a command line tool. While wrestling with parameters can be a bit challenging, it allows us to run it from a script, so we have good chances to end up with a simple, double-clickable command.

On Debian/Ubuntu based systems it's as simple as:

sudo apt-get install qemu-system-x86 qemu-kvm qemu-utils

On other Linuxes there should be similar commands and similar packages.

A word regarding qemu-kvm: simplified, this is a kernel module which speeds up emulation a lot, like 5- or 10-fold (depending on the task at hand). However, it requires these 'virtualisation features' in your CPU, so it won't run on every PC, especially not the low end ones. While this could be countered with some patience easily, Android apparently requires this higher speed, so you can't go without. Bad. For testing I ran Android with and without the module; with the module it booted in 2:10 minutes, without it didn't within 180 minutes.

There's a project which is dedicated to build Android for x386-based hardware, Android-x86. They host ready to use ISO images on the Android-x86 download page and on the Fosshub download page. I grabbed the latest generic ISO image (note the file extension). As of this writing, the file's name was android-x86-5.1-rc1.iso.

Let's do a test run to see wether and how things work:

qemu-system-i386 -enable-kvm -m 1024 -soundhw es1370 \
  -net nic -net user -cdrom /path/to/android-x86-5.1-rc1.iso

This is sufficient to boot the emulated device. -m 1024 gives the device a 1024 MiB of RAM. 512 MiB are sufficient for booting, too, but then things become unreliable at setup already.

• At the bootloader screen, just hit Enter (or wait 60 seconds).
• Clicking into the emulator window will catch the mouse inside the emulated device, then you can operate there. To escape, press and release ctrl and alt on the PC keyboard at the same time.
• When asked to enter a SIM card, click Skip in the lower right corner.
• When asked to connect to WiFi, skip as well. Network connections will work anyways.
• When entering text or passwords, be aware that your keyboard has the US-english layout, not the layout of the operating system qemu is running in.
• Don't pause too long, once Android enters sleep mode you can't escape from that. It's a good idea to set sleep to 30 minutes in Settings -> Display -> Sleep after finishing setup.
• To stop Android, close the emulator window. This is like removing the battery from a running phone, but it works.

Can you finish setup, start up the browser and surf around the web? Excellent, test passed!

A note about privacy: if you care about your privacy, be aware that whatever you enter, do or upload, will be forwarded to Google. Googles business is to collect and analyse such data, similar to NSA. You can skip connecting to your Google account, but then you can't install applications. That said, there is no connection between the host PC and the emulated Android device, they don't even share the same IP address. So, if you create a new Google account from within the emulated device, your stuff is pretty safe. Later we'll install Android onto an emulated hard drive, so it's even possible to use different hard drives for distinct identities, making it impossible for Google to draw a connection between your various accounts. Unless you exploit that connection yourself by entering the same credentials or by using the same account, of course.

To remove the need to start over each time Android is launched, we need some permanent storage device: an emulated hard disk. Creating such a disk is rather simple:

qemu-img create -f qcow2 android.img 2G

Yupp, that's just two Gibibytes. Android its self will need about 800 MiB, the remaining space is for apps. You need more only if you want to store larger amounts of data on the emulated device, like picture or music collections.

The obvious first step for an installation is to run Android with both, the CD-ROM and the hard disk mounted:

qemu-system-i386 -enable-kvm -m 1024 -soundhw es1370 \
  -net nic -net user -cdrom /path/to/android-x86-5.1-rc1.iso \
  -hda /path/to/android.img -boot d

At the boot screen, choose Installation, you'll end up in the partition chooser after a few seconds.

Operating all these installation tools with their poor-man's GUI is simple: simply hit the Tab key until the right field is highlighted, then hit Enter to execute. Tabbing wraps around, so once you accidently got too far, simply continue until the choice starts over.

If the partition chooser lists sda1, you can skip creating a partition, there is already one. If the first entry reads sda (without number), you have to create a partition. Without partition we have no partition table, so we can't mark the disk as bootable.

Creating a partition:

• Choose Create/Modify partitions.
• Don't use GPT.
• You enter cfdisk. Choose [New].
• Hit Enter another two times, until you're back to the selection menu. This creates a single, primary partition as big as the entire disk. A typical choice for emulated hard disks.
• Choose [Bootable], in the Flags column above the word “Boot” should appear.
• Choose [Write], confirm with yes (look at what you type). This writes the partition table.
• Choose [Quit], you're done with partitioning.

The partition chooser should now list sda1, with number. This is the volume we want to install Android onto.

• Choose sda1.
• Format to ext4 (or ext3, if ext4 isn't available).
• Confirm.
• Install GRUB (else there's nothing loading the OS).
• Skip installing EFI GRUB2.
• Do not install /system as read-write.

Just a few seconds later, depending on your physical hard drive speed, the installer will offer to run Android or reboot. Instead of doing either, close the Qemu window. You're ready to run Android the regular way already.

In case you messed up somewhere along the way, simply close the Qemu window and start over. You didn't write data so far, so you can't loose any.

From now on we have a installed device, the distribution CD-ROM is obsolete. Accordingly there's no point in mounting it, we can run the emulator like this:

qemu-system-i386 -enable-kvm -m 1024 -soundhw es1370 \
  -net nic -net user -hda /path/to/android.img

On the first run after an installation you'll have to go through setup again, and it's a bit more lengthy now. Still it's a good idea to do it carefully this time, it's the last time it has to be done.

Here are a few commonly done procedures in loose order.

In Android, go to Settings -> Language & Input and look at Physical keyboard. This is the input method with which Qemu forwards keystrokes to Android.

Changing the keyboard layout is a bit complicated: click on the one entry there, then Set up keyboard layouts. In this dialog you can checkmark one or more layouts. Having this done, go back with the left arrow in the black bottom bar. Then click on the bullet point to the right of the layout name, even if there is only one choice. Now you have a new keyboard layout, you can test it e.g. in the Internet Browser.

Note: there's also a way to let Qemu map the keyboard, which should work during installation already. Didn't test this. If you happen to know how and/or how well it works, please edit this page to add a description here.

One of these nagging annoyances is, that many, many apps insist on running in portrait mode; which means the screen is higher than wide.

The situation is a bit unfortunate, because Qemu lets the operating system ( = Android) choose which size the screen should be, while Android expects the hardware ( = Qemu) to do this. Result: neither cares, the screen defaults to 1024×768 pixels.

The solution is to ask Grub, the bootloader, to set a screen size. Thank you to Thierry Delprat at Nuxeo, who got me onto the right track:

1. Launch the emulator like normal, but at the boot screen, choose Debug Mode.
2. When booting stops at a shell prompt, make the system volume writeable by typing this: mount -o remount,rw /mnt
3. Then edit Grub's boot menu: vi /mnt/grub/menu.lst
4. Look for the first line starting with 'kernel' and add this at the end (type 'A'): DPI=240 UVESA_MODE=800×1280 (spaces between each pair of parameters).
5. Hit the Esc key to leave edit mode and save the file (type ':wq').
6. To make sure everything gets written to disk, remount back to read-only: mount -o remount,ro /mnt

Now you can close the emulation window and start up again.

Well, no, doesn't work. qemu has to be changed to support custom screen resolutions. For hints see https://www.tablix.org/~avian/blog/archives/2013/05/custom_display_resolutions_in_qemu/ and https://bugs.launchpad.net/qemu/+bug/1054558 and … I just subscribed to the qemu mailing list in order to get a command line option into qemu.

That's basically the same as when using Qemu, but with graphical user interface (GUI). Using a GUI doesn't make installation exactly easier, because you can no longer copy&paste commands. No need to describe the details here, Laptop Magazine did already.

Android Developer Tools comes with an emulator, too. The emulator isn't available standalone, but installing SDK Tools only at least reduces the overhead. Still you end up with several gigabytes and tens of thousands of files to get an emulated device running.

Well, if it boots at all. When doing a quick test with emulating a Nexus One with Android 5.1.1 it didn't boot within 90 minutes. Trying Android 6.0 on a Nexus One or a Nexus 7 didn't even get that far, the emulator window simply vanishes a minute after launch.

You're not a DIYer? Then it's still possible to run Android apps on a PC.

BlueStacks is an Android emulator for PC and Mac. Note that it looks like it stores personal data of the emulated apps (your data!) on its own servers, so don't expect privacy.

Some parts aren't exactly obvious, so let's try to find an answer.

That's correct, both operation systems are based on the Linux kernel. Still there are several reasons why one can't simply run application binaries made for one on the other one:

• Android and Ubuntu are customised differently. That's actually true for most Linux distributions, so it's always troublesome to run an application made for one distribution on another.
• Having a need for custom binaries is usually no problem on Linuxes, because each distribution also comes with it's own package management or has tools to build binaries easily, so you can find all the applications custom-built for each distribution. But most Android apps are, unlike in the Ubuntu ecosystem, not Open Source, so another distribution can't recompile them.
• Android is built with phones and tablets in mind, which feature hardware typically not existing on desktop PCs. For example a telephony connection, a GPS receiver, a touch screen. Many Android apps expect such peripherals to be present, so they have to be emulated on the desktop.

True, Android apps are written in Java. But it's a customised flavour of Java, so Ubuntus generic Java virtual machine isn't sufficient. AFAIK, the Android Java wasn't ported to generic Linuxes, yet, so it can't be installed on Ubuntu directly.

On top of this there's the same issue as with the question above: Android apps expect typical telephony hardware to be present, so this hardware has to be emulated on a desktop.