Android runs fine in qubes, no mouse issue, But

First of all this is my laptop; MSI GL63 8RC, core i5 8th gen with upgraded RAM to 24 GB.

Installing android.iso in a standalone HVM does pass the moment when it says “OK. There is no hard drive to edit partitions.” But if I simply run android.iso in live mode, without actually installing, it works. I get no problems at all. No mouse problems as mentioned in various topics across the internet. But only issue I was getting is that everytime I poweroff my machine, I have to reboot android.iso in live mode which means I have to reinstall all the apps and sign in… etc. Which is obviously a frustrating. So, I passed the usb controller to HVM. Connected a 16 gig USB drive and booted from android.iso. This time I installed the android on a usb drive and obviously it worked. No errors like “OK. There is no hard drive to edit partitions.” Now if I need to use my android HVM, I simply pass the usb controller to the HVM, connect the USB drive and it boots fine, works great. Don’t have to reinstall apps every time I reboot.

But now the problem is that my laptop has only one USB controller which controls 3 USB type A and 1 USB type C port. So, if I pass that controller to the android HVM, I cannot any other usb devices in other app VMs, including my wireless mouse. Although,my touchpad works, but I don’t like using touchpad a lot.
My devices that I can pass to HVM;

I have explained my situation. So is there anyway possible that I can either install the android.iso on qubes HVM’s virtual drive? Or could I use my USB wireless mouse across the entire qubes OS even if I pass the usb controller to HVM where I am booting it from usb-drive-android?

1 Like

There is a workround which I have here:

I’d like to say its documented, but it isn’t.
Also, that is directed at reactOS, but it’s trivial to change to allow
Android qubes to see a drive at /dev/sda, which I believe is the main
problem with installs.

If you need help with it let me know.

I would definitely need some help doing it. Because I have no idea about these codes. But also, I won’t be that hard to explain these things. So, if you can, I would really appreciate this.

The problem is that the existing code forces drives to /dev/xvd*.
reactOS and Android installers require /dev/sda.
It should be possible to customise the qube definition with an extra
drive at /dev/sda, but I have never got this to work. (Other custom
configs do work as expected: if anyone does have the custom disk config
working please post details.)

So this workround alters the code so that for specific qubes the code is
altered to provide sd* drives.

The actual change is made in init_patch, and uses a case statement
to apply, depending on the qube_name. If you want to apply to
Android-XXX qubes, then change ‘react*’ to ‘Android*’
Because of the wild card every qube with name beginning with Android
will reflect the change.

path_init is a bash script, that copies the existing
stubdom-linux-rootfs, and then extracts out the files.
Then the init file is patched using init_patch

A new stubdom-linux-rootfs is created and finally copied into place.

The sed statement is not hard to understand, and the bash script should
be easy to follow. So you should feel confident in running this in dom0.

You can revert at any time if you have kept a copy of the file you are
changing. Just copy that back in to place in /usr/lib/xen/boot/.

Hope this helps - if you have any more questions, ask away. (I’m off to
bed now, but will pick up in the morning.)

1 Like

As I said, I am no good with codes. So, I wanna know if it’s safe to run this thing in dom0 because they say don’t touch dom0.
And just to make me feel okay, is there anyway to make this happen without touching dom0?

Depends on what you mean by this.

You don’t have to run the code in dom0, but you would need to replace
the file in dom0.
Is it safe? I’ve been running it for some time.
Or do you mean, will the changes made to the system affect your
security? I doubt that.
Anyone should be able to review that code and comment. Anyone?

If you want more detail on what’s happening here, I’ve an explanation at:

So, where and how do I run the script? Again, I have no knowledge of coding. And this is the file that I have to replace;
And earlier you said, I should change the “react” to “android”. But if I just just create an HVM named “react-***” and install android in it, do I still need to change that?

And yes, I am worried about the security. And I understand it’s open source. So, I don’t really need to overthink this. But just to ease my mind, once my android qube is all set and running, can I just back up that HVM and reinstall qubes OS itself, restore back up? Will it still work or will I have to replace the file again?

You are right to be cautious - no problem with that.
stubdom-linux-rootfs-orig-20200517 is my copy of my file.
You can/should take a copy of the file from your system and store it in
/home/user. I date mark mine for convenience.

The file you need to replace is the source file -
stubdom-linux-rootfs. The script will do this automatically.

Yes, any qube called “reactxxxxx” will be affected, so you can do
what you’ve outlined and install android there.
N.B I cant speak to the performance of an android qube on your system -
it would be good to get some feedback on this.

And finally, being open source is no guarantee of security (ssh). It
only helps if someone reviews the code.
This isnt complex, and anyone should be able to confirm that it does
what it says on the tin and no more. Anyone??

Okay, so I just download the script and run where? You said not in dom0. And if I create an standalone HVM for installing android, means I have to choose “install your own OS”, So, can’t run a terminal in there. Right? So, where?

And yeah, open source doesn’t necessarily means secured, it’s just better than closed source and anyone can review it, but it’s certainly not me, at least not yet.

I’m still waiting on your response.

Where do I run it if not in dom0?

You can run it in any qube, as it’s just bash and sed, which are quite
But you’ll have to copy the file out of dom0, and then copy the updated
file back in to dom0.

if I create an standalone HVM for installing android, means I have to choose “install your own OS”, So, can’t run a terminal in there. Right? Or if I can, I never found any options

Yes - if you create a standalone qube, then the only way to run just
a terminal is to have Qubes graphic tools installed. You can do this
with standalones which have OS for which Qubes packages are available -
Fedora, Debian, Ubuntu, Centos, Arch, etc.

Thanks for all the support and patience. I am going to try it now. And if anything pops up beyond my understanding, I’ll bother you again. And if all goes well, I’ll post the results.

@HashBrown, if you manage to successfully install an Android VM on Qubes, I would very much appreciate (and I think I am not alone!) if you could write a detailed procedure containing each step to achieve that result!

There are bits on the web but I never found a complete procedure.


I’ve put some notes up at

It’s a complete guide to setting up an Android qube using Android-x86.
The process should be absolutely straightforward, and the resulting qube
is usable. You could try one of the cm flavours, but although
installation seems fine, I have found them unreliable. YMMV.


1 Like

So far, I have tried the steps as given. Only changed one step which is;

cp /usr/lib/xen/boot/stubdom-linux-rootfs > stubdom-linux-rootfs.orig

to ‘qvm-copy-to-vm qubes1 /usr/lib/xen/boot/stubdom-linux-rootfs’, don’t think it really matters.

After running ./patch_init it asked me if I should replace a read only file, I said yes.

And still getting stuck to same screen “Ok. There is no hard drive…”. Tried with multiple android ISOs. Now downloading the ISO, you have mentioned in the post. But don’t think that’s gonna make any differences either.

have not tried this on x86 android but i have the same approach as unman (i borrow from

i hacked my stubdom init file to do the workarounds if the qube name end with ‘-ide’

i really need a github but here is the process:

note: ‘hacking’ is the name of the qube you will do the hacking in to modify the stubdom rootfs

  1. in dom0 (send the stubdom root to hacking qube):
qvm-copy-to-vm hacking /usr/lib/xen/boot/stubdom-linux-rootfs
  1. hacking qube (patch init file):
cd ~/QubesIncoming/dom0
mkdir stubdom && cd stubdom
zcat ../stubdom-linux-rootfs|cpio -i -d -H newc --no-absolute-filenames

cat << 'INITPATCH' > ../patch.tmp
case "$(xenstore-read "/local/domain/$domid/name")" in
     echo "performing IDE hack since qube ends with -ide"
     dm_args=$(echo "$dm_args" | sed "s/-drive${SP}file=\/dev\/xvd\(.\),if=none,id=disk\(.\),format=host_device,cache=writeback,readonly=off${SP}-device${SP}scsi-hd,bus=scsi0.0,drive=disk.,wwn=0x352540005175626./-drive${SP}if=ide,media=disk,file=\/dev\/xvd\1,id=disk\2,format=host_device,cache=writeback,readonly=off/g")

#super hacky patching since fedora did not have patch by def
sed -i "/^IFS=\\$'\\\x1b.*/r ../patch.tmp" init
find . -print0 | cpio --null -ov --format=newc | gzip -9 > ../stubdom-linux-rootfs.idehack

cat <<'DOM0INSTALL' > ../
cd /usr/lib/xen/boot
sudo cp -p stubdom-linux-rootfs stubdom-linux-rootfs.backup
sudo cp ~/stubdom-linux-rootfs.idehack stubdom-linux-rootfs
  1. back in dom0 (install):
cd ~
qvm-run --pass-io hacking 'tar -C ~/QubesIncoming/dom0 -cf - stubdom-linux-rootfs.idehack' | tar -xv

this way all i do is create hvm and make sure name ends with -ide and it will get ide drive

ps: xen updates or qubes os might over write the stubdom. this is just a hack!

1 Like

ps: why is most sponsors of android x86 web site casino and online game sites? haha