Docker for Android SDK
Pinned Loading
Docker for Android SDK 30 with preinstalled build tools and emulator image
Docker for Android SDK 29 with preinstalled build tools and emulator image
Docker for Android SDK 28 with preinstalled build tools and emulator image
Docker for Android SDK 27 with preinstalled build tools and emulator image
Docker for Android SDK 26 with preinstalled build tools and emulator image
Docker for Android SDK 25 with preinstalled build tools and emulator image
Docker for Android SDK 21 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 22 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 23 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 24 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 25 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 26 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 27 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 28 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 29 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
Docker for Android SDK 30 with preinstalled build tools and emulator image
0 Updated Jul 13, 2021
People
Top languages
Most used topics
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Источник
Сборка Android-проекта в Docker-контейнере
Разрабатывая проект под платформу Android, даже самый небольшой, рано или поздно приходится сталкиваться с окружением для разработки. Кроме Android SDK, необходимо чтобы была последняя версия Kotlin, Gradle, platform-tools, build-tools. И если на машине разработчика все эти зависимости решаются в большей мере с помощью Android Studio IDE, то на сервере CI/CD каждое обновление может превратиться в головную боль. И если в web-разработке, решением проблемы окружения стандартом стал Docker, то почему-бы не попробовать решить с помощью него аналогичную проблему и в Android-разработке…
Для тех, кто не знает что такое Docker — если совсем просто, то это инструмент создания т.н. «контейнеров» где содержится минимальное ядро ОС и необходимый набор ПО, которые мы можем разворачивать где захотим, сохраняя при этом окружение. Что именно будет в нашем контейнере определяется в Dockerfile, который потом собирается в образ запускаемый где угодно и обладающий свойства идемпотентности.
Процесс установки и основы Docker прекрасно описаны на его официальном сайте. Поэтому, забегая немного вперед, вот такой Dockerfile у нас получился
Сохраняем его в папку с нашим Android-проектом и запускаем сборку контейнера командой
Параметр -t задает tag или имя нашего контейнера, которое обычно состоит из его название и версии. В нашем случае мы назвали его android-build а в версии указали совокупность версий gradle, android-sdk и platform-tools. В дальнейшем нам проще будет искать нужный нам образ по имени используя такую «версию».
После того как сборка прошла мы можем использовать наш образ локально, можем загрузить его командой docker push в публичный или приватный репозиторий образов чтобы скачивать его на другие машины.
В качестве примера соберем локально проект. Для этого в папке с проектом выполним команду
Разберем что она означает:
docker run — сама команда запуска образа
-rm — означает что после остановки контейнера он удаляет за собой все что создавалось в процессе его жизни
-v «$PWD»:/home/gradle/ — монтирует текущую папку с нашим Android-проектом во внутреннюю папку контейнера /home/gradle/
-w /home/gradle — задает рабочую директорию контейнера
android-build:5.4.1-28-27 — имя нашего контейнера, который мы собрали
gradle assembleDebug — собственно команда сборки, которая собирает наш проект
Если все сложиться удачно, то через пару секунд/минут вы увидите у себя на экране что-то вроде BUILD SUCCESSFUL in 8m 3s! А в папке app/build/output/apk будет лежать собранное приложение.
Аналогичным образом можно выполнять другие задачи gradle — проверять проект, запускать тесты и т.д. Основное преимущество — при необходимости сборки проекта на любой другой машине, нам не нужно беспокоиться об установке всего окружения и достаточно будет скачать необходимый образ и запустить в нем сборку.
Контейнер не хранит никаких изменений, и каждая сборка запускается с нуля, что с одной стороны гарантирует идентичность сборки независимо от места ее запуска, с другой стороны каждый раз приходиться скачивать все зависимости и компилировать весь код заново, а это иногда может занимать существенное время. Поэтому кроме обычного «холодного» запуска у нас есть вариант запуска сборки с сохранением т.н. «кэша», где мы сохраняем папку
/.gradle просто копируя ее в рабочую папку проекта, а в начале следующей сборки возвращаем ее обратно. Все процедуры копирования мы вынесли в отдельные скрипты и сама команда запуска у нас стала выглядеть так
В итоге, среднее время сборки проекта у нас сократилось в несколько раз (в зависимости от числа зависимостей на проекте, но средний проект таким образом стал собираться за 1 минуту вместо 5 минут).
Все это само собой имеет смысл только если у вас есть собственный внутренний CI/CD сервер, поддержкой которого вы сами и занимаетесь. Но сейчас есть много облачных сервисов в которых все эти проблемы решены и вам не надо об этом переживать и нужные свойства сборки можно так же указать в настройках проекта.
Источник
Computer Science Blog
on computer science and media topics
Android SDK and emulator in Docker for testing
During our Android development project, we had to cope with several technological and organizational challenges with regard to construct a stable CI pipeline. Due to our chosen stack of Docker containers for building and deploying we had to confront with the topic how to integrate and deploy a building and testing environment for Android in Docker.
For a better understanding of this challenge following illustration of our stack can be consulted:
We recognize that our docker environment is built up in three containers. The “build”-Container with a Jenkins environment at the bottom. Our “database”-Container in the center and our “SDK and Emulator”-container on top.
Following challenges have emerged:
- How to set-up a build environment for Jenkins in which the Android SDK dependency is located in a different Docker container?
- How to deploy the build artifacts on this emulator and run UI-Tests
For a better understanding of our first challenge we must understand how we run an Android build in Jenkins.
We used a standard pipeline project for this task which is separated in four Stages:
Each stage is responsible for an automated step in the build process. In case of an Android build several stages are gradle commands. This means that especially stage two and three are essential.
Step two builds a runnable Android artefact, respectively an .APK file. Step three executes the Android project’s unit tests. To run these gradle commands in a pipeline script you can use a gradle wrapper. A gradle wrapper encapsulates a specific gradle version in the project or installs a specific version if needed. Or You can specify and install gradle through the available Gradle Plugin for Jenkins:
See https://wiki.jenkins.io/display/JENKINS/Gradle+Plugin.
Another thing is the configuration of the stages is the pipeline script. To invoke gradle commands you should wrap gradle in a separate command like:
By declaring this function, you can start any gradle operation by passing the gradle command in the parameter.
As said at the beginning, gradle uses the Android SDK to build and tests the project. To find the Android SDK gradle resolves it by default in the environment variable ANDROID_HOME.
But what do you have to do if the path of ANDROID_HOME is located in another Docker container?
We solved this problem by declaring a Volume for the Android SDK by providing it for our Jenkins container. If you use Docker compose you can easily declare a volume from one container to expose it for another. By doing this you can create a shared path between two or more containers. This could look like this:
As you can see a volume called “app-volume” is created. In the android-emulator image the SDK is located in /root/ and will be mapped to /usr/local/android-sdk in the Jenkins image. Now you only must make sure that your android emulator image is up and running and you have to set the ANDROID_HOME variable to this location.
Now that we can build our Android App with the SDK from the emulator container we can put our focus on UI-Tests and deploying on a Docker-driven Emulator:
If you search in Docker Hub for Android Emulator you will find a couple results. Our experience was that most of these Docker images were outdated or not maintained anymore. The problem is that often after updating the SDK via SDKMANAGER the requirements to the environments are changing. This means that commands in the startup script are often deprecated, so you should build an image by yourself or search a recent image that is not older than a couple of weeks. In our case the image docker-android-x86-7.1.1 from butomo1989 was well matching. You can find his Docker repo here.
Butomo1989 did a great job creating this image. He provides some nice features in his build.
For example:
- noVNC Support (You can connect via Browser to a running emulator)
- You can run UI Tests with different 3-rd party frameworks (like Appium, Espresso)
- And many more
Google provides its own UI Testing framework. It is called the Espresso framework. The tests are written in JUnit4 Style. An example can be seen here.
In our fifth Stage which is called “Test on emulator” we call our emulator by adb. Make sure you have the Android Debug Bridge installed on your Host machine. In our case the adb must be installed in the Jenkins-Docker image.
You can connect to the emulator device just by calling it in the pipeline script:
After a successful connection the adb test command can be called:
Источник
Docker hub android sdk
Android SDK development environment Docker image
It contains the complete Android SDK enviroment, is able to perform all regular Android jobs.
Solves the problem of «It works on my machine, but not on XXX machine«.
Some tool (e.g. Infer), which has complex dependencies might be in conflict with your local environment. Installing the tool within a Docker container is the easiest and perfect solution.
Works out of the box as an Android CI build enviroment.
Provide only the barebone SDK (the latest official minimal package) gives you the maximum flexibility in tailoring your own SDK tools for your project. You can maintain an external persistent SDK directory, and mount it to any container. In this way, you don’t have to waste time on downloading over and over again, meanwhile, without having any unnecessary package. Additionally, instead of one dedicated Docker image per Android API level (which will end up with a ton of images), you just have to deal with one image. Last but not least, not to redistribute the SDK is the legal behavior.
Gradle and Kotlin compiler come together with this Docker image merely for the sake of convenience / trial.
It is recommended to always execute a build with the Wrapper to ensure a reliable, controlled and standardized execution of the build. Using the Wrapper looks almost exactly like running the build with a Gradle installation. In case the Gradle distribution is not available on the machine, the Wrapper will download it and store in the local file system. Any subsequent build invocation is going to reuse the existing local distribution as long as the distribution URL in the Gradle properties doesn’t change.
Using the Gradle Wrapper lets you build with a precise Gradle version, in order to eliminate any Gradle version problem.
- /gradle/wrapper/gradle-wrapper.properties specifies the Gradle version
- Gradle will be downloaded and unzipped to
/.gradle/wrapper/dists/
Previously, running Android SDK update within the Dockerfile or inside a container would fail with AUFS storage driver, it was due to hardlink move operations (during updating Android SDK) are not supported by AUFS storage driver, but changing it to other storage driver would work. Fortunately, it’s not the case any more. With the latest version of Docker Engine, it works like a charm, you can do whatever you prefer. If you’re not interested in the technical cause, simply skip this section (jump to the next section).
What happens if the update fails?
To prevent this problem from happening, and you don’t wanna bother modifying storage driver. The only solution is to mount an external SDK volume from host to container. Then you are free to try any of below approaches.
Update SDK in the usual way but directly inside container.
Update SDK from host directory (Remember: the host machine must be the same target architecture as the container — x86_64 Linux ).
If you by accident update SDK on a host machine which has a mismatch target architecture than the container, some binaries won’t be executable in container any longer.
AUFS storage driver was deprecated in Docker Community Edition 18.06.0-ce-mac70 2018-07-25. And AUFS support was removed in Docker Community Edition 2.0.0.0-mac78 2018-11-19. For more details, please check Docker for Mac Stable release notes.
More information about storage driver:
Check Docker’s current storage driver option
Check which filesystems are supported by the running host kernel
Some storage drivers only work with specific backing filesystems. Check supported backing filesystems for further details.
In order to change the storage driver, you need to edit the daemon configuration file, or go to Docker Desktop -> Preferences. -> Daemon -> Advanced.
A helper script is provided at /opt/license_accepter.sh for accepting the SDK and its various licenses. This is helpful in non-interactive environments such as CI builds.
It is also possible if you wanna connect to container via SSH. There are three different approaches.
Build an image on your own, with a built-in authorized_keys
Mount authorized_keys file from the host to a container
Copy a local authorized_keys file to a container
That’s it! Now it’s up and running, you can ssh to it
And, in case you need, you can still attach to the running container (not via ssh) by
Remote access to the container’s desktop might be helpful if you plan to run emulator inside the container.
When the container is up and running, use your favorite VNC client to connect to it:
Password (with control): android
Password (view only): docker
For more details, please refer to Emulator section.
VNC client recommendation
You can host the Android SDK in one host-independent place, and share it across different containers. One solution is using NFS (Network File System).
To make the container consume the NFS, you can try either way below:
Mount the NFS onto your host machine, then run container with volume option ( -v ).
Use a Docker volume plugin, for instance Convoy plugin.
And here are instructions for configuring a NFS server (on Ubuntu):
Gradle Distributions Mirror Server
There is still room for optimization: recent distribution of Gradle is around 100MB, imagine different containers / build jobs have to perform downloading over and over again, and it has high influence upon your network bandwidth. Setting up a local Gradle distributions mirror server would significantly boost your download speed.
Fortunately, you can easily build such a mirror server docker image on your own.
Preferably, you should run the download script locally, and mount the download directory to the container.
Starting from now on, gradle wrapper will download gradle distributions from your local mirror server, lightning fast! The downloaded distribution will be uncompressed to /root/.gradle/wrapper/dists .
If you don’t want to bother with SSL certificate, you can simply change the distributionUrl inside [YOUR_PROJECT]/gradle/wrapper/gradle-wrapper.properties from https to http .
ARM emulator is host machine independent, can run anywhere — Linux, macOS, VM and etc. While the performance is a bit poor. On the contrary, x86 emulator requires KVM, which means only runnable on Linux.
VM acceleration restrictions
Note the following restrictions of VM acceleration:
You can’t run a VM-accelerated emulator inside another VM, such as a VM hosted by VirtualBox, VMWare, or Docker. You must run the emulator directly on your system hardware.
You can’t run software that uses another virtualization technology at the same time that you run the accelerated emulator. For example, VirtualBox, VMWare, and Docker currently use a different virtualization technology, so you can’t run them at the same time as the accelerated emulator.
Preconditions on the host machine (for x86 emulator)
Read KVM Installation if you haven’t got KVM installed on the host yet.
Check the capability of running KVM
Load KVM module on the host
Check if KVM module is successfully loaded
Where can I run x86 emulator
Linux physical machine
Cloud computing services (must support nested virtualization)
Note: there will be a performance penalty, primarily for CPU bound workloads and I/O bound workloads.
VirtualBox (since 6.0.0, it started supporting nested virtualization, which could be turned on by «Enable Nested VT-x/AMD-V», but at the moment, it’s only for AMD CPUs)
How to run emulator
Check available emulator system images from remote SDK repository
Make sure that the required SDK packages are installed, you can find out by above command. To install, use the command below. Whenever you see error complains about ANDROID_SDK_ROOT , such as PANIC: Cannot find AVD system path. Please define ANDROID_SDK_ROOT or PANIC: Broken AVD system path. Check your ANDROID_SDK_ROOT value , it means that you need to install following packages.
Download emulator system image(s) (on the host machine)
Run Docker container in privileged mode (not necessary for ARM emulator)
Check acceleration ability (not necessary for ARM emulator)
Create a new Android Virtual Device
List existing Android Virtual Devices
Launch emulator in background
Check the virtual device status
Now you can for instance run UI tests on the emulator (just remember, the performance is POOR):
If you encounter an error «Process system isn’t responding» in the emulator, like below:
Increase the limit of the memory resource available to Docker Engine.
Increase the amount of physical RAM on the emulator by setting / changing hw.ramSize in the AVD’s configuration file ( config.ini ). By default, it’s not set and the default value is «96» (in megabytes). You could simply set a new value via this command: echo «hw.ramSize=1024» >> /root/.android/avd/ .avd/config.ini
Access the emulator from outside
Default adb server port: 5037
Outside the container:
Make sure that your adb client talks to the adb server inside the container, instead of the local one on the host machine. This can be achieved by running adb kill-server (to kill the local server if it’s already up) before firing adb connect command above.
You can give a container access to host’s USB Android devices.
Connect Android device via USB on host first;
Disconnect and connect Android device on USB;
Select OK for «Allow USB debugging» on Android device;
Now the Android device will show up inside the container ( adb devices ).
Don’t worry about adbkey or adbkey.pub under /.android , not required.
Unfortunately it is not possible to pass through a USB device (or a serial port) to a container.
Firebase Test Lab
You can also run UI tests on Google’s Firebase Test Lab with emulators or physical devices.
To create and configure a project on the platform:
Create a project in Google Cloud Platform if you haven’t created one yet.
Create a project in Firebase:
Choose the recently created Google Cloud Platform project to add Firebase services to it.
Confirm Firebase billing plan.
Go to IAM & Admin -> Service Accounts in Google Cloud Platform:
Edit the Firebase Admin SDK Service Agent account.
Keys -> ADD KEY -> Create new key -> Key type: JSON -> CREATE.
Download and save the created private key to your computer.
Go to IAM & Admin -> IAM in Google Cloud Platform:
Edit the Firebase Admin SDK Service Agent account.
ADD ANOTHER ROLE -> Role: Project -> Editor -> SAVE.
Go to API Library -> search for Cloud Testing API and Cloud Tool Results API -> enable them.
Once finished setup, you can then launch a container to deploy UI tests to Firebase Test Lab:
Later you can view the test results (including the recorded video of test execution) in Firebase Console, open your project, navigate to Test Lab.
To learn more about Firebase Test Lab and Google Cloud SDK, please go and visit below links:
Android Commands Reference
Check installed Android SDK tools version
The » android » command is deprecated. For command-line tools, use cmdline-tools/tools/bin/sdkmanager and cmdline-tools/tools/bin/avdmanager .
List installed and available packages
Update all installed packages to the latest version
The packages argument is an SDK-style path as shown with the —list command, wrapped in quotes (for example, «extras;android;m2repository» ). You can pass multiple package paths, separated with a space, but they must each be wrapped in their own set of quotes.
Sometimes you may encounter OOM (Out of Memory) issue. The issues vary in logs, while you could find the essence by checking the exit code ( echo $? ).
For demonstration, below examples try to execute MemoryFiller which can fill memory up quickly.
Exit Code 137 (= 128 + 9 = SIGKILL = Killed)
Commentary: The process was in extreme resource starvation, thus was killed by the kernel OOM killer. This happens when JVM max heap size > actual container memory. Similarly, the logs could look like this when running a gradle task in an Android project: Process ‘Gradle Test Executor 1’ finished with non-zero exit value 137 .
Exit Code 1 (= SIGHUP = Hangup)
Commentary: With enabling Docker memory limits transparency for JVM, JVM is able to correctly estimate the max heap size, and it won’t be killed by the kernel OOM killer any more. Similarly, the logs could look like this when running a gradle task in an Android project: Process ‘Gradle Test Executor 1’ finished with non-zero exit value 1 . In this case, you should either check your code or tweak your memory limit for container (or JVM heap parameters, or even the host memory size).
Exit Code 3 (= SIGQUIT = Quit)
Commentary: JRockit JVM exits on the first occurrence of an OOM error. It can be used if you prefer restarting an instance of JRockit JVM rather than handling OOM errors.
Exit Code 134 (= 128 + 6 = SIGABRT = Abort)
Commentary: JRockit JVM crashes and produces text and binary crash files when an OOM error occurs. When JVM crashes with a fatal error, an error report file hs_err_pid***.log will be generated in the same working directory.
JVM is not container aware, and always guesses about the memory resource (for JDK version earlier than 8u131 or 9).
Many tools (such as free , vmstat , top ) were invented before the existence of cgroups, thus they have no clue about the resources limits.
-XX:MaxRAMFraction : maximum fraction (1/n) of real memory used for maximum heap size ( -XX:MaxHeapSize / -Xmx ), the default value is 4.
-XX:MaxMetaspaceSize : where class metadata reside. -XX:MaxPermSize is deprecated in JDK 8. It used to be Permanent Generation space before JDK 8, which could cause java.lang.OutOfMemoryError: PermGen problem.
-XshowSettings:category : shows settings and continues. Possible category arguments for this option include the following: all (all categories of settings, the default value), locale (settings related to locale), properties (settings related to system properties), vm (settings of the JVM). To get JVM Max Heap Size, simply run java -XshowSettings:vm -version
-XX:+PrintFlagsFinal : print all VM flags after argument and ergonomic processing. You can run java -XX:+PrintFlagsFinal -version to get all information.
By default, Android Gradle Plugin sets the maxProcessCount to 4 (the maximum number of concurrent processes that can be used to dex). Total Memory = maxProcessCount * javaMaxHeapSize
Earlier in JDK 8, you need to set the environment variable _JAVA_OPTIONS to -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap . Then you’ll see such logs like Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap during any task execution, which means it takes effect. JDK 10 has introduced -XX:+UseContainerSupport which is enabled by default to improve the execution and configurability of Java running in Docker containers. Since JDK 1.8.0_191, -XX:+UseContainerSupport was also backported, then you don’t need to set -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap any more. UseCGroupMemoryLimitForHeap was deprecated in JDK 10 and removed in JDK 11.
JAVA_OPTS environment variable won’t be used by JVM directly, but sometimes get recognized by other apps (e.g. Apache Tomcat) as configuration. If you want to use it for any Java executable, do it like this: java $JAVA_OPTS .
The official JAVA_TOOL_OPTIONS environment variable is provided to augment a command line, so that command line options can be passed without accessing or modifying the launch command. It is recognized by all VMs.
You can tweak -Xms or -Xmx on your own to specify the initial or maximum heap size.
How to enable the remote API (for CI purpose)
Go to the top-level directory of this project
Execute version_inspector.sh script inside a docker container from local machine
Your contribution is always welcome, which will for sure make the Android SDK Docker solution better. Please check the contributing guide to get started! Thank you ☺
Stargazers over time
Copyright © 2016-2021 Jing Li. It is released under the Apache License. See the LICENSE file for details.
By continuing to use this Docker Image, you accept the terms in below license agreement.
Источник
