Performance and resource recommendations

[QAutomatron]

Hey, I tried to use this docker image but faced several things related mainly to performance. I would be grateful for your help or advice.

Mainly using api28 image, built from the latest emulator_api_28_x86 branch

• Emulator boot time. I use different types of cloud instances(on GCE), but the average boot time from logs ~ 120000 ms. Sometimes it follows with emulator: VERBOSE: System.cpp:1486: Timed out with running command |/opt/android-sdk-linux/platform-tools/adb -s emulator-5554 shell pm revoke com.google.android.googlequicksearchbox android.permission.RECORD_AUDIO |

Most of the time it also resolves in "System UI not responding" message on the emulator screen which results in failed tests. How can I fix it?

• Are there any scalable examples besides k8s farm? If I just want to create 10-20 emulators of 1 API image and connect CI container to run tests on them? I use simple docker-compose with a scale, but emulator start time is still questionable.

• Do you have any CPU\Memory recommendations for host instances? According to api28 config, one emulator should use 2 cores and 3Gb of memory of the host machine.

[Dartlexx]

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.

[Malinskiy]

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.

[QAutomatron]

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).

[Malinskiy]

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?

[QAutomatron]

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.

[QAutomatron]

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.