Android x86 Installation and Troubleshooting Procedures

For users who want to have an Android experience on their desktop, there are a handful of Android-based operating systems out there – however, many of them are really just forks of Android x86 (PrimeOS, Remix OS, Phoenix OS x86). This is because Android x86 slowed down development for awhile, and thus other developers took up in its absence.

However, Android x86 has been releasing steady updates as of late, including an update to Android Oreo. So if you want to enjoy a great Android experience on your desktop, its a good idea to try out Android x86 before trying one of the other forks (Remix OS has totally stopped development, for example).


If you are on Ubuntu, you can grab UNetbootin with the terminal command: sudo apt-get install unetbootin

If you are on Arch Linux, you can use: pacman -S unetbootin

USB Flash Drive Installation

  1. Launch UNetbootin and point it to your Android x86 ISO file.
  2. Now choose “USB Drive” and click OK.
  3. UNetbootin will begin copying Android x86 to your USB flash drive, turning it into a portable installer.
  4. When the process is complete, reboot your computer, and boot into your BIOS menu.
  5. Find the page on your BIOS that allows you to boot directly to a specific media (HDD, CD, USB, etc).
  6. Choose to boot directly to USB flash drive.
  7. A GRUB menu will appear, choose to install Android x86 to your hard drive.
  8. You will now need to choose a partition to install to – if you’re unsure, do not format the partition. Also don’t overwrite your other OS partition, obviously.
  9. A new prompt will come up, asking if you want to install GRUB. If you are primarily using Windows with no other Linux OS on your computer, choose Yes. If you already have a Linux OS / GRUB on your PC, it’s a terrible idea to install over it.
  10. Another prompt will come up, asking to “Make system R/W”. Choose yes. This will “root” Android x86 and enable read-write access to the /system partition.
  11. Reboot your computer, and enjoy your fresh Android x86 installation.

For CD / DVD Installation

The installation process is nearly exactly the same, except that you will burn a bootable CD from the Android x86 ISO. There’s a really a ton of ISO burners out there – you could just go with Free ISO Burner.

Installing to a Virtual Machine

  1. Configure your VM to have a minimum of 512 MB of RAM, though with the latest Oreo-based Android x86, this should probably be a bit higher.
  2. Load the Android x86 ISO file into your VM menu, and load the VM.
  3. A GRUB menu will appear, choose to install Android x86 to hard disk.
  4. Create a new partition, and install Android x86 to it. Format the partition to one of the supported formats – ext3, ext2, ntfs, and fat32. Please note if you choose fat32, a warning will appear that you cannot save data to fat32 – thus, Android x86 will function as a live CD (no data will be saved to the system as you are using it).
  5. Choose “Yes” when it asks to Install bootloader GRUB, and allow it to make the system R/W to enable root.
  6. Reboot when everything is done.

Adding Android x86 to the GRUB Menu

Install GRUB Customizer first, it will make this process much easier.

sudo add-apt-repository ppa:danielrichter2007/grub-customizer

sudo apt-get update

sudo apt-get install grub-customizer

Now launch GRUB Customizer, and add a new GRUB entry.

Click the ‘Sources’ tab, and enter these commands:

set root='(hd0,4)'

search --no-floppy --fs-uuid --set=root e1f9de05-8d18-48aa-8f08-f0377f663de3

linux androidx86/kernel root=UUID=e1f9de05-8d18-48aa-8f08-f0377f663de3 quiet androidboot.hardware=generic_x86 SRC=/androidx86 acpi_sleep=s3_bios,s3_mode

initrd androidx86/initrd.img

If you notice, we bolded a few parts in those commands. That is because you need to change them as follows.

For set root='(hd0,4)’, change the (hd0,4) to the partition where Android x86 is installed.

HD0 means SDA, so if you install Android x86 to SDB, it will be HD1, etc. The number afterwards is the partition number. So hd0,4 would be SDA4, for example – if you installed Android x86 on SDA6, then you will change it to hd0,6.

For the part –set=root e1f9de05-8d18-48aa-8f08-f0377f663de3, the random string is the UUID of the partition where Android x86 was installed. You need to change it to the correct UUID. You can obtain your correct UUID by creating a new entry in GRUB Customizer, then going into the Options tab, and choosing the ‘Linux’ option from the dropdown menu.

In the partition dropdown menu, you need to choose your partition, then go to the Source tab. It will display your UUID.

Where we bolded androidx86/, this is the root of Android x86. You need to change it to your actual Android x86 root, by going into your Android x86 partition. You should see a folder named ‘android’, and that will be the root of your Android x86 installation.

androidboot.hardware is going to be your specific device. If you’re using an older version of Android x86, such as the Android 4.03 versions, you need to change it to androidboot_hardware (with an _ underscore, not a . period). This is entirely unnecessary for latest Android x86 versions. When androidboot.hardware is not set in kernel cmdline, the init process would still get the correct value of ro.hardware. This eliminates the necessity of androidboot.hardware.

Here’s the list of hardware you can change it to:

  • generic_x86: If your hardware isn’t listed, use this
  • eeepc: EEEPC laptops
  • asus_laptop: ASUS laptops (supported ASUS laptops only)

Final Tips and Tricks

Android x86 is unable to use Android Market, so there are alternative solutions to obtaining Android apps.

First you should enable unknown sources. Go to Settings > Applications > enable Unknown Sources, and ignore the warning dialogue.

Now you can download and install APKs from outside of Google Play. There’s a ton of third-party app stores out there, just be really careful. Some of the better stores are:

How to Display Correct Battery Value

Android was developed for specific batteries in mind, thus an Android-based OS will show incorrect battery values on different hardware platforms (such as a laptop). In order to correct this, there are a few things to tweak.

In Linux, applications collect the battery status through sysfs, where the battery status is located in /sys/class/power_supply/. Different platforms, however, may give you a different directory layout under /sys/class/power_supply/, but Android hardcodes the directory layout to /sys/class/power_supply/. To resolve this issue, you can add new entries in vendor/asus/eeepc/system.prop, where the user can change the value of these entries to correctly configure the sysfs directory layout for different platforms. These entries are:
ro.sys.fs.power_supply.bat.feature.voltage.full=/voltage_full is not supported
#ro.sys.fs.power_supply.bat.features.bat.temperature is not supported

In essence, these entries tell the Android battery service code to look for the information in the correct place.

To implement your own battery status handling code, simply re-implement the IBatteryServiceStatus class in frameworks/base/libs/utils/IBatteryServiceStatus.cpp, replacing frameworks/base/libs/utils/BatteryServiceStatus.cpp with your own implementation.

To Wake up the Machine

Unlike other OS, you cannot simply wake up the system from sleep status by moving around the mouse or hitting a random keyboard button.

You can only use ESC, Menu, left, right, up and down keys to wake up the system. To wake up the system, you have to hold the keys mentioned above for at least 1 second. You can push menu key when keyguard screen showing up to unlock screen, and you can use mouse to turn the wheel on the keyguard screen to unlock screen.

How to boot Android x86 on Unsupported Graphics

When booting the Live-CD, on the menu that offers various boot options, hit the Tab key on your keyboard. This will display the boot prompt.

Now you should see something like:

kernel initrd=/initrd.img root=/dev/ram0
androidboot_hardware=generic_x86 acpi_sleep=s3_bios,s3_mode video=-16
quiet SRC= DATA= DPI=240

You should edit this line, first by removing “quiet” to see what the kernel messages are displaying.

Then you can set different video mode parameters. You can use NoModeSet, which disables the kernel mode setting and instructs the kernel to not automatically set the graphic resolution. Alternatively you can use Xforcevesa, which enforces using the VESA driver.

Play with these parameters to see which works for you – you can also set them both together “nomodeset xforcevesa”.


Kamil Anwar

Kamil is a certified MCITP, CCNA (W), CCNA (S) and a former British Computer Society Member with over 9 years of experience Configuring, Deploying and Managing Switches, Firewalls and Domain Controllers also an old-school still active on FreeNode.