Comment by lfy_google | Hacker News Reader

Comment by lfy_google | Hacker News Reader

Parent Full thread

I'm on the emulator team; we've considered this route before, but the hard part about maintaining a simulator is that the contact surface with the host OS is much larger, making it so that we would essentially have to port the current year's version of Android, with all java/C userspace APIs, to all wanted host OSes. This would require much greater resources dedicated to this porting than we're able to handle, and/or we'd need to make the hard choice of only maintaining certain Android versions and skipping certain ones completely. It would also be very difficult to maintain fidelity.

With full virtualization, the contact surface is restricted to a few low level bits in the kernel along with a few HALs/drivers that need to talk to the host for meaningful/fast I/O, like input/network/graphics, and everything else can be kept stock with no modification. This allows us to ship largely the same binaries that would go on a dedicated Android device and have it be able to run on windows/macos/linux easily, and it's how we've been able to keep up with the pace of yearly Android releases.

Edit: Oh and note that we are totally aware of and bummed out by emulator's increasing resource usage as android version bumps up, to the point we're afraid that the next one will finally be the one that really needs all resources of a modern PC; as such, we're looking into ways to minimize the cpu/ram/disk footprint of the system images, keeping only the bits that are actually needed for testing apps (with Google Play Services, and being better at maintaining/promoting more stock AOSP images in the case where GMS isn't needed)

As anecdote I don't run the emulator since years, as I am not going to buy a last generation PC to keep running it at average speeds.

On all my PCs it is faster to build to device than having to deal with the emulator competing with Android Studio for hardware resources.

Not everyone has Google level budgets for hardware.

Since the switch to x86 images with VT-x acceleration & GPU pass-through the emulator has gotten massively faster.

Neither of which required anything resembling a latest generation hardware. Try it again before you pretend your experiences years ago are still relevant.

Than why does HAXM refuse to install on this computer?

I tell you why, you have forgotten to mention that "Extended Page Tables (EPT), and Unrestricted Guest (UG) features" are also required.

Which are 12 & 10 year old features, respectively.

Which goes back to my original post,

> Not everyone has Google level budgets for hardware.

Given that my current one runs Windows 10 64bit Pro, Visual Studio 2019, OpenJDK 14, clang 10 and Eclipse 2020‑03 just fine, I am not upgrading a perfectly working computer just to make Android emulator, or are you offering to get me one?

Specially since it was a Google's decision to drop support for its capabilities around Android 7 emulator release.

And your point is obviously ridiculously untrue. You're complaining about poor performance (not that it doesn't work, mind you, just that it's slow), while also refusing to upgrade to a system from the last decade.

You can get a system that will run the emulator with great performance for less than $50 on Ebay. There's no possible way to describe or classify this as requiring "Google level budgets for hardware." If you can't afford to upgrade that sucks, but you also can't at all make a reasonable complaint about performance when insisting on using a 10+ year old system.

If we're all throwing spaghetti at the wall here, what do I know, but maybe create an android-sdk OS that one may boot into and is heavily optimized for (speedy) android development?

Yep, that basically sums up what we're looking into---a system image that still keeps up with the latest API levels and features introduced in the latest Android OS, but has minimal impact on resources.

Have you thought about streaming emulators from the cloud? I know it sounds crazy but if we can stream games, why not android emulator?

Thanks for the interest! We've been exploring this in limited ways; for example, https://github.com/google/android-emulator-container-scripts contains a set of Python/Docker/JS scripts for setting up WebRTC streaming of emulators remotely. More to come soon.

We’re doing just that at https://testingbot.com : stream android emulators and even physical devices. You can control these through your own browser.

I'm very interested in this. I usually run into crashes in production on specific devices that I don't own. It would be nice to be able to reproduce them on a virtual device. FYI, the site is not loading atm.

With WSL2 being a full(-ish) VM, running Android on a Linux base might be interesting (especially when using a Linux host, see the other anbox comment). Not sure how to deal with macOS though.

And yeah, as of Android Studio 3.x (was waiting for the official 4.0 release), it was trying to nudge towards using the Google Play Services images pretty hard.

> With WSL2 being a full(-ish) VM, running Android on a Linux base might be interesting (especially when using a Linux host, see the other anbox comment). Not sure how to deal with macOS though.

But this is pretty much what Android Emulator is - a fullish VM on a Linux base.

Yes, but that's different in that it's x86 on x86 so you can use hardware paravirtualization features for maximum performance (through HyperV). ARM on x86 can't use hardware virtualization features, you have to run it all in software, which is why it's slow. Big value in getting rid of the architecture mismatch.

Android Emulator has been (by default) x86 for years now and it's using both hardware paravirtualization and even OpenGL passthrough.

I thought WSL was a compatibility layer similar to Wine, not a full VM?

WSL1 was a translation layer. WSL2 is a VM.

The original WSL(1) was. However, the new version, WSL2, brings a lot of architecture changes. Now its basically a virtualized Linux running in Hyper-V. The nice thing about that new architecture is that now applications like Docker can use WSL2 to run the containers which was not possible with previous versions.

Have you considered https://anbox.io ?

Thanks, I've read about this before but just went over it again in more detail yesterday with a fresh look.

So this is basically the simulator situation, but with easier management of which libraries the guest userspace can dlopen and files to read()/write().

It's much like current Android-on-ChromeOS capabilities where containers are used to isolate where the "guest" userspace libraries are stored, so that it's not necessary to interop well with things like the host version of libc for example.

However, the problems come when considering the interface to the host kernel and hardware. Here are just two of the showstoppers:

1. Android expects to run on a particular range of kernel versions and configs each release. Fidelity is sacrificed to run with a wide range of Linux host kernel configurations. It's also easy for components on the host system such as SELinux to interfere with guest operation (and Android itself expects to use its own version of SELinux...so which one wins in the end?).

2. Further customization in the guest userspace needs to be made to account for needing to interop with a regular Linux system; e.g., input/network/display will be much more code that touches various parts of guest userspace and potentially hurts fidelity versus the VM abstraction where they are fake hardware and no customization of guest userspace is needed.

There are also isolation issues that involve more delicate dances, such as how to prevent runaway resource usage in the container from hogging the whole system (VMs merely waste the #vcpus + RAM dedicated to them; while that can be a lot compared to the host, it's explicitly controllable).

These problems sound less serious on the surface versus porting the Android framework directly to the host OS, but in the end it's basically the same level of essential complexity; containers just let you remove the incidental complexity of guest userspace libraries leaking into your /usr/lib and interop w/ your filesyste.

And once we try to run on non-Linux systems we're back at square one needing to port all userspace code to the host OS (Unless you're running Docker on macOS/Windows in which case you'd be creating a VM again, sacrificing all the benefits of containers versus VMs while keeping the complex customizations).

This is probably why Microsoft is pushing WSL2, ChromeOS skipped Android 10 support and is looking into ARCVM, and anbox is still running Android 7.1.1 (w/ plans to update but skipping releases in the meantime).

Mind pinging me internally? Username in profile.

I have... an idea.

Reply on news.ycombinator.com