Performance and resource recommendations about docker-emulator-android HOT 6 OPEN

Hello, sure, I will try to help you.

We are also using the api28 image and emulator_api_28_x86 branch in our Kubernetes cluster.

First of all, I might tell you that expectation of 3GBs of RAM is an incorrect one - 3GB is a RAM in that is emulated in the device.
But this docker image also provides other types of memory to the qemu (such as cache, etc.), so in my experience, it starts with usage of 4Gb and goes up to 9-10 Gb.

Well, we don't run it anywhere except for Kubernetes, so I can't give you a different example. We are using snapshot versions of a docker image (Makefile creates both). And in our experience start of emulator really takes 30-60 seconds, that's why they are spawned only 2 times a day in our cluster and run 12 hours.

from docker-emulator-android.

There is an option to startup using the snapshot to speed up the init process but keep in mind that a lot of emulator options will no be changeable this way, for example, the serial number of the device. Each time you change these - you'll have to recreate another docker image for the emulator. From the maintenance perspective, this will be a nightmare, but it might be an acceptable trade-off in some use-cases.

from docker-emulator-android.

Thank you for such a quick reply.

I did not notice the option with snapshot images right away (it was not mentioned in the readme), tried it and it is much better now. But I also noticed that when creating a snapshot, adb is renamed, so the only option is to adb connect to exposed 5555 port. Are there any other options?

What about CPU usage per emulator? Config in api-28 set to 2. Is it worth limiting the resources of a container to 2 or 2.5 CPU?

But even with a snapshot, I'm still facing "System UI isn't responding" error especially when I run several containers at once (5+) on one instance(32 cores, 120Gb memory).

from docker-emulator-android.

This is intentional behavior as for the adb: the reason is that by default the emulator will connect to a local instance of adb server and you will not be able to connect to it externally. Even if you might succeed you will have the problem of two adb servers "fighting" so to say for control over that device. The only viable way to disable this was to rename the adb binary.

The performance of emulator depends highly on each specific environment. It is especially slow if you're using nested virtualisation which usually happens on public cloud providers such as AWS/etc. Are you running the container on actual hardware or you're using some kind of virtualisation there?

from docker-emulator-android.

This is intentional behavior as for the adb: the reason is that by default the emulator will connect to a local instance of adb server and you will not be able to connect to it externally.

Got it. So if I just want to connect all running emulators to local adb on same machine (or host network) I can comment line with renaming.

Are you running the container on actual hardware or you're using some kind of virtualisation there?

Thanks. Yes, I'm trying to use nested virtualization instances on Google Cloud for now, but it seems that despite the hardware I choose, performance is fine only if there are just a couple of simulators per machine running. I will try to run this on "real" hardware then.

from docker-emulator-android.

Thank you again for your advice. The problem has been solved. Using "metal" instance - significantly improves performance when running multiple emulators within a single host.

from docker-emulator-android.