How to run android automation scripts with docker environment.
The testing process is a very complex and extensive procedure. The testing process itself helps to understand and identify defects, errors, and failures that were created during development. The testing process itself takes a lot of time and resources. But the largest amount of resources are spent on mobile testing of Android or iOS. Mobile testing requires the installation of a large number of dependencies. It is also necessary to have a large enough fleet of devices (so-called device farms) to perform Manual and automated scenarios.
Using Docker containerization technology, we can create and run automated scripts for multiple branches of functions, speeding up development and increasing productivity.
Suppose you are to set up test automation. Building and maintaining a whole test infrastructure all by your team can be painful. Although some cloud services like Sauce Labs do cover DevOps, you may have hesitated to use them due to security issues or budget concerns in your company. Docker is a good tool for setting up and maintaining servers for test automation, especially if you are just starting to build an automation test infrastructure with open source solutions.
In this article, we create an Android container to isolate the testing process.
Whichever test framework or test library you are using, you need to consider the library version, environment variable settings, and other dependencies when implementing and executing a test. A test script is a program that sends requests to the server to execute commands on the driver you want to test against. To enable anyone in your team to execute the test on any platform, you can use Docker to pack all test scripts and libraries as a test runner container. The container is an isolated environment that includes all environment settings and libraries, so the test scripts can be run on any platform. Here is an example of a Dockerfile to make a simple test runner Docker image. Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.
Start a Docker Container.
The image that we build on top of is — ubuntu:latest
- —
it: interactively execute shell cmd. — name "name-of-your-android-container”: prefer the container’s name.
Also to run docker as non-root, the simplest way is adding the current user to group docker:
Install SDK and all Packages.
Gradle.
Make a new directory /opt/gradlew and install gradle-wrapper there. (The directory names can be anything, but save the files somewhere easy to find)
Android SDK.
The Android software development kit (SDK) includes different components, including SDK Tools, Build Tools, and Platform Tools. The SDK Tools primarily includes the stock Android emulator, hierarchy viewer, SDK manager, and ProGuard. The Build Tools primarily include apt (an Android packaging tool to create . APK), dx (an Android tool that converts .java files to .dex files). Platform Tools include the Android debug shell, sqlite3, and Systrace.
You need to download the SDK manually without Android Studio bundled, using SDK tools only.
The most important packages are platform-tools, tools and emulator . Run this to install them quickly:
platform-toolscontainsadbtoolscontainsavdmanagerandsdkamanageremulator: run emulatorsystem-images;android-29;google_apis;x86: use to create avd
Accept all licenses of Android SDK:
Now create an avd test:
Check to see if it works!
Run Emulator.
Here are some minor steps before running the emulator:
- Stop any running emulators with ADB.
- Start emulator in the background with flag
-no-windowand-gpu off. - Turn off animation to avoid flaky tests.
Some test cases will act on a view that might be not visible on a small screen — so we set the emulator up to have a high resolution (1180x2220)
Very often we need to run our automation scripts to a different OS. This is usually because the operating system on a PC can be Windows, Linux, or Mac OS. CI systems typically run on Linux. With all this variety, we need a simple start-up. I recommend using the following implementation:
the emulator startup script may look like this:
Start the emulator with sh create-emulator.sh or ./create-emulator.sh and wait until Boot Status: 1, which means the device is fully loaded and ready to use.
Check again by entering bg to see the background jobs.
On Unix-like operating systems, bg is a job control command. It resumes suspended jobs in the background, returning the user to the shell prompt while the job runs.
Syntax
bg [job]job — Specifies the job that you want to run in the background. Job number 1 is referred to as %1, job number 2 is referred to as %2, etc.; %, %+, or %% refers to the current job; %- or — refers to the previous job.
Also, I recommend creating shell scripts to delete the emulator from the AVD manager:
You can check the successful creation of the emulator with the following command:
$ adb devices
We have an Android emulator running in the container successfully!
Build a Docker image.
Open a new terminal tab, stop name-of-your-android-container and commit your changes to create a new Docker image:
Test once again:
For further use, we need to create a Dockerfile:
To automate the process of applying licenses for different versions, you need to create a file license_accepter.sh with the following content:
Build the Project and Run Tests.
Check out your project configurations and build the docker image with appropriate arguments:
Enter the top level of your project directory and run:
- -it: interactive mode.
- — rm: remove volume after the process is completed.
- -v
$PWD:/project: mount your directory into the container:/project - “android-container”: name of your container.
- bash
-c “ . /create-emulator.sh && gradlew build -p /project”: create the emulator and mount folder with the project.
Conclusion
Docker is not only for software development but can be manipulated for software testing. It lets you set up and scale-out remote servers either for web UI or mobile testing. By having an isolated and stable environment, everyone can perform the test inside a container to verify the system functions at any development stage. All containers in this infrastructure can be created on-demand and destroyed when the test is finished. It makes the test infrastructure flexible and maximizes the machine resource. Try to use Docker to build a flexible and disposable test infrastructure for web UI and mobile testing.
