Mac android emulator very slow full#
Mac android emulator very slow license#

Migrating our CI infrastructure and tests to Android Virtual Devices (AVDs) wasn’t without its own challenges. This year’s advances in platform-independent emulator deployment using Docker images added extra fuel to the simmering idea of migrating to the Android Emulator (more on Docker-based emulation a bit further down in this post).Īfter repeatedly evaluating the stability and performance of the Android Emulator between 2017 and now, our team finally decided this year that the current state of the emulator and the benefits of switching to it would outweigh the necessary migration work - so we made the switch. This meant that we required expensive macOS machines to run our CI infrastructure.

Mac android emulator very slow full#

Something that prevented us from scaling our Genymotion instances was that Genymotion requires a full desktop environment to be running, since there is no way to run it in headless mode. Also, since the licensing system of Genymotion turned out to be cumbersome, the necessary work to keep the Genymotion machines up and running turned out to be substantial. With only a hand full of Genymotion instances running in our CI, we felt the need for additional CI power but didn’t want our yearly costs to explode. This cost time and got on our nerves.Ĭost-effective scaling was another concern. Having the Android Emulator locally but Genymotion on CI made it more difficult for us to reproduce test issues that only happened on CI machines. The simplicity of setting up the Android Emulator also ousted Genymotion from being used by our Android developers locally during development. This ease of setup is especially useful for other teams (like our QA team or other platform teams) that are less fond of Android development processes.

Mac android emulator very slow license#

Since the emulator ships as part of the Android SDK, it is much simpler to acquire and set up than Genymotion is (the latter also requires developers to sign up and purchase a license before being able to download and use the virtual device). Moreover, there were additional reasons that ultimately motivated us to move away from Genymotion: With Project Marble, Google also invested time and effort in improving the speed and stability of its virtual devices, bringing them up to speed with (or even beyond) Genymotion when used for local development and CI purposes. In recent years, Google took notice of the lack of performance and stability of its developer tools and the Android Emulator. However, there were also downsides to using Genymotion (high license costs, maintenance effort, complicated setup, etc.), which, over the years, caused us to look into alternative solutions. Naturally, we also adopted Genymotion here at PSPDFKit, using it both for fast local development and for running our CI. Since Genymotion runs the Android OS inside a VirtualBox VM and is capable of running Android at high speeds, even on less performant developer machines, it was the go-to choice for most Android developers when it arrived on the scene. Luckily for us, Genymotion solved our problem with these issues by providing an x86-based virtual device that was fast and stable. It was also notoriously unstable, which made it unsuitable for CI use. Sadly, the Android emulator used to be quite slow, because it was actually emulating an ARM CPU. Having a solid and well-tested framework is one of our main priorities, and as such, having the CI infrastructure to ensure that every merge gets tested is very important.

Let’s start out by looking into why we chose to use Genymotion to start with.

This had been a long time coming, and there were many reasons for us to switch, which we will discuss in detail in this blog post. Earlier this year, we switched our complete CI infrastructure from using Genymotion to using the Android Emulator.