The first step is to define a unique name and port for the emulator instance of our current job, which enables us to run multiple emulators on one host:Īnd with that, we were ready to run our tests on CI. This allows us to run multiple CI jobs and emulator instances in parallel on a single physical machine. We are managing our CI using Buildkite (which replaced our Jenkins CI). The outline for how we run the emulator on our CI machines works as detailed below.
#Genymotion mac android
Set up the emulator to run directly on “bare metal” Linux machines by deploying the Android SDK to those machines.Įnsure all of our instrumented tests run inside the new emulator.ĭo the “dockerization” of our emulators as a follow-up step. Since setting up Docker to run our tests properly posed an additional hurdle (turns out fixing tests in a headless machine inside Docker is kind of complicated), we settled on the following strategy to get the emulator running on our CI machines: 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.
#Genymotion mac 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.
#Genymotion mac 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.
0 kommentar(er)
