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 Comments
Leave a Reply. |