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. We have not tested using QEMU hypervisor with a VPN: though it may work, we recommend disabling your VPN while using Genymotion Desktop if the virtual device fails to start.Earlier this year, we switched our complete CI infrastructure from using Genymotion to using the Android Emulator.

Locate the Host-only interface that corresponds to Genymotion virtual device(s) (usually called vboxnetX for Linux and macos, and VirtualBox Host-only ethernet adapter for Windows).Start VirtualBox outside of Genymotion Desktop.If you are using custom settings, or if this range is unavailable for some reason, follow these steps to identify the range to exclude: To do so, please contact your network administrator or refer to this article.īy default, the IP range to exclude is 192.168.56.0/24 To solve this, you must configure An圜onnect so that the local traffic is not sent to the VPN. An error is thus displayed and the launch is aborted. This prevents Genymotion Desktop to connect to the virtual device. For example, the Cisco An圜onnect VPN client changes the routing table of your workstation in order to send the whole network traffic to the VPN.