#Genymotion pricing full#
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.
#Genymotion pricing android#
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. 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)
