By Lingfeng Yang, Android Studio Team

Developers often use Android emulators to quickly test modified applications before submitting code in their daily development work. In addition, developers are increasingly using simulators in their CI (Continuous Integration) systems to run larger-scale automated tests. To better support these use cases, we open-source the Android Emulator Container Script and improve the development experience around the following two pain points:

  • Deployable: Find and run the Android emulator for the version you want.
  • Debuggability: Tracks errors from remote instances of the Android emulator.

Can be deployed sex

Android supports a variety of hardware and software configurations, and the Android emulator is no exception. However, this diversity can lead to confusion in the configuration of the test environment. How do developers get emulator and system image files? What drivers are required? How do I turn on or off CPU or GPU acceleration? And so on and so on.

To solve these problems, we introduced:

  • Android Emulator Download script – This script provides an up-to-date list of Emulator images (both AOSP and the version that includes the Google Play service) and Emulator binaries (for Linux, Mac OS, and Windows). You can integrate it with existing CI systems. Going forward, we plan to enhance the service so that it can download deprecated versions in addition to the latest version, making it easier for developers to reproduce historical test results.
  • Android Emulator Docker – With Android images and emulators, this is just the beginning. Runtime environment, drivers, and pre-installed system dependencies. We’ve packaged the Docker image generator together to make the complete runtime environment for the Android emulator. After starting Docker mirroring, 1) port forwarding and ADB and 2) gRPC and WebRTC make interaction with the emulator possible. Currently, Docker image generators are designed to run on Linux. We’re also working on support for Mac OS and Windows, so stay tuned!

To improve reproducibility, the underlying Dockerfile template makes the required command line identifiers and system dependencies more explicit (and can be reproduced by building Docker images from it). For hardware acceleration, note the –privileged flag passed to run.sh; We assume that CPU acceleration can be used when running the emulator and that a — Privileged is needed to run the CONTAINER with CPU acceleration (KVM) enabled.

For more details on how to create and deploy Android emulator images, see the README file in the documentation.

Debugging can be

When the simulator is running a test and the test fails, it may be difficult for you to intervene in the running test environment and diagnose errors. Diagnostics often require direct interaction with virtual devices, and we provide two mechanisms for direct interaction:

  • ADB
  • The remote flow

For ADB, we support running all commands (such as logcat and shell) by forwarding a specific port from Docker to the host. The current port in use is 5555, and we need to gather more feedback and do more research on how best to allocate ports between different containers.

The remote flow

A security note: With remote streams, anyone who can connect to your computer on port 80/443 can interact with the emulator once the service is started. So keep this in mind when running remote streams on public servers!

You can use remote flows to run emulators in containers with the same interaction capabilities as the local runtime. Running the emulator in the container makes it easier to debug problems that are difficult to find using ADB commands. You can access the emulator using a browser that supports WebRTC for streaming video, and gRPC for sending mouse and keyboard events to the emulator. Remote flows require three containers:

A container with an Envoy Web Proxy (for gRPC) a container equipped with Nginx for running the React Web application

You can compose docker containers together using Docker-compose, as described in README. The container is bound to ports 80 and 443, so make sure you are not running a Web server. If you point the browser to the host, we provide a self-signed certificate. When you point your browser at the host, you should see something like the following:

Again, anyone with access to the host can interact with the emulator

Testing, more testing

Testing seems to drag out development even longer. However, as many experienced developers have seen, good automated testing can actually speed up development as the code on a project becomes more complex. The purpose of continuous testing is to make sure that every change does not adversely affect the application.

What are your thoughts and questions about CI and continuous testing? Feel free to share them in the comments section.

Click here toLearn more about the Android emulator