Note that we are passing networkhost in order to share the host’s network identity: docker run -i -t -networkhost ubuntu:14.04 /bin/bash -c 'sudo apt-get update & sudo apt-get install -y android-tools-adb & /bin. This years advances in platform-independent emulator deployment using Docker.Now, I will start a container in Docker with Ubuntu 14.04 and automatically install ADB before dropping to a prompt. Initially, It Worked for UsThis meant that we required expensive macOS machines to run our CI infrastructure. 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.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. If your IDE and SDK are up to date, then creating an x86 AVD is generally pretty straightforward.Luckily for us, Genymotion solved our problem with these issues by providing an x86-based virtual device that was fast and stable. Using an x86 system image can speed up the emulator considerably, so this is the option you’ll typically want to opt for. It was also notoriously unstable, which made it unsuitable for CI use.The Android emulator supports system images that emulate two different CPUs: ARM and Intel x86. Sadly, the Android emulator used to be quite slow, because it was actually emulating an ARM CPU. Docker host: macOS Sierra.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.
![]() Android Emulator Docker License Before BeingThis made us reconsider using it.Moreover, there were additional reasons that ultimately motivated us to move away from Genymotion: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). 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. Why the EmulatorIn recent years, Google took notice of the lack of performance and stability of its developer tools and the Android Emulator. Unfortunately I met the following error(s) while trying to.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. Persona 4 emulator for macWith 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.Cost-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 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:And 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. 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:Set up the emulator to run directly on “bare metal” Linux machines by deploying the Android SDK to those machines.Ensure all of our instrumented tests run inside the new emulator.Do the “dockerization” of our emulators as a follow-up step.The outline for how we run the emulator on our CI machines works as detailed below.We are managing our CI using Buildkite (which replaced our Jenkins CI). Migrating from Genymotion to AVDsMigrating our CI infrastructure and tests to Android Virtual Devices (AVDs) wasn’t without its own challenges. This meant that we required expensive macOS machines to run our CI infrastructure.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).After 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. Best free driver booster for macWhile our new test devices emulated the same hardware (our tests use the Nexus 5X template), system UI changes between Android 5 and Android 9 made our tests fail because coordinates were still off from the expected output and they needed updating.Tests that relied on being run on a specific API version for the behavior they were checking. For example, we had tests that asserted views, and, after applying some touch gestures to them, these tests contained specific hardcoded bounds. During the migration, there were two kinds of tests that needed updating:UI tests that rely on the specific size of a device. That’s because we also used this moment as an opportunity to update the Android version we run our tests on, and since we’ve had years of tests written to run on a 5.0.1 Genymotion device, we had to update all of our tests to work on our new test platform. Making Our Tests Run in The EmulatorFor us, the work wasn’t done here. ![]() The Orchestrator runs each test case in a separate process, ensuring that all cases run completely isolated from the rest of the test suite, thereby preventing tests from failing due to state leaking between them. Android Test OrchestratorAnother improvement we want to look into in the future is enabling the Android Test Orchestrator. Furthermore, using Docker would also enable us to run tests inside our own cloud-based infrastructure (like on Google Cloud, AWS, or Azure) for easier scaling. This is probably related to our own custom test runner, and it shouldn’t deter you from using the Orchestrator. While it was easy to fix incompatible test names by avoiding path separators in them, it took some time to track this limitation down due to obscure test error messages and missing information in the Orchestrator documentation.The other issue we are encountering is the test execution randomly stopping without any exception or other log pointing toward why. We found out that the Orchestrator doesn’t support path separators (”/”) inside test names because it creates a separate file for each test case it executes based on the test’s name. At the time of writing this post, we have already started looking into enabling this and run into two different issues.The first issue is that previously written parameterized tests started to fail when we ran them using the Orchestrator. While switching to the official Android Emulator took time and effort, the investment has already paid off, with faster CI speeds, better stability, and improved ease of use. We showed that while Genymotion was a great fit for us in the past, the combination of Google’s investment in the Android Emulator and our ever-changing requirements made the emulator the better choice for us. SummaryIn this blog post, we presented our journey of Android Virtual Device-testing at PSPDFKit.
0 Comments
Leave a Reply. |
AuthorAmanda ArchivesCategories |