the one thing linux really hasnt been made on par with winblows yet is the dreadful amount of options for android simulation -the most popular choice seems to be Waydroid, but its such an unneeded hassle to set up at all -genymotion is just slow -and than you have things like android x86 which entirely defeat the point of an emulator
VM = x86 = android-x86 which OP already mentioned
yeah but android emulators = VM = x86 = android-x86
There’s a bit more to an emulator than simply running Android on x86 hardware.
not really no. I mean, sure you could add a fancy gui on top of it. but 90% of android emulators are some kind of android x86 + libhoudini/ndk + vmm. some modify surfaceflinger so that each application will render to it’s own window, but usually it’s just disabling launcher, and sending some kind of command to open the app from a gui (IE. sending adb launch commands)
deleted by creator
Yes and no.
In general it is true that an emulator just needs to translate instructions, but for things like games and the Android operating system, your emulator also needs to use whatever hardware acceleration you have or it will run like dogshit.
Android makes extensive use of graphical acceleration to the point where it is a mandatory requirement. There is no part of the UI that doesn’t use hardware acceleration.
Luckily Android uses OpenGL ES, and there are means to translate that into Vulkan without too much issue.
But what you’re talking about is virtualisation for the most part - the only thing arguably doing any actual emulation in your scenario is libhoudini. Otherwise, there isn’t any translation of instructions - The Android VM instructions get executed directly on Ring 0 of the CPU
and? vbox, qemu, hyperv and vmware, all have gpu acceleration to a degree. Qemu will also be getting vulkan acceleration soon
EDIT: forgot crosvm (google play games) which does too
And therefore it means that in addition to doing translation work, they themselves need to implement hardware acceleration. That’s why you see many game emulators requiring DirectX even if the console in question never used it.
Oh, and 4 of the 5 products you mentioned are not emulators. Of the 5, only QEMU is fully capable of emulation. There is a massive and important difference between virtual machines and emulation.
nearly every single emulator, for Windows is a VM pretty much. Blue stacks, memuplay, WSA, Google Play games.
no, there is no difference between virtualization and emulation. virtualizations just hardware accelerated emulation. That’s it. If you use blue stacks and call it emulation, because it’s emulation, all the sudden it’s not emulation because it’s virtualization?
If that is the bar, then there are incredibly few Android emulators. Yes some Android emulators, or rather virtualizers, do implement some custom GPU acceleration stuff. but not all, Google Play games uses CrossVM with vulkan cereal, WSA uses their weird stack. genymotion IIRC uses virgl, so does qemu.
EDIT: by the way, with VirtualBox VMware so and so forth, you are still emulating. you are emulating NICs, oftentimes you are emulating GPU, you are emulating storage controllers, you are emulating PCI controllers, so on and so forth.
Yes there is.
Actually it’s the opposite: virtualisation does as little emulation as possible. At a high level, it acts more as a ring-fence around native resources than an actual emulator. With most virtualisation, the only things that are getting emulated are minor components with little computing involved like sound and networking cards.
The reason virtualisation is so fast compared to emulation is because it’s running the code as-is and not translating it.
That is correct. You basically have QEMU and that’s it.
Not exactly. If you are not doing GPU passthrough, either fixed or mediated, most virtualisation software use API forwarding for 3D acceleration APIs. That is, the hypervisor passes calls to Vulkan, DirectX, etc, from the guest to the host, has the host’s GPU render it, then pass it back.
GPU emulation is a very last resort, as the performance is dreadful.