AndroidSDK

Android SDK development environment Docker image

Goals

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.

Philosophy

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, according to Android's terms and conditions, one may not redistribute the SDK or any part of the SDK.

Note

Gradle and Kotlin compiler come together with this Docker image merely for the sake of convenience / trial.

Using the Gradle Wrapper

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.

<your_project>/gradle/wrapper/gradle-wrapper.properties specifies the Gradle version
Gradle will be downloaded and unzipped to ~/.gradle/wrapper/dists/
kotlin-compiler-embeddable-x.y.z.jar will be resolved and downloaded when executing a Gradle task, it's defined in <your_project>/build.gradle as classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"

Caveat

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?

ls $ANDROID_HOME/cmdline-tools/tools/
#=> empty, nothing is there
# tools such as: android, sdkmanager, emulator, lint and etc. are gone

android
#=> bash: android: command not found

sdkmanager
#=> bash: /opt/android-sdk/cmdline-tools/tools/bin/sdkmanager: No such file or directory

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.

gradle <some_task>
#=> Error: java.util.concurrent.ExecutionException: java.lang.RuntimeException: AAPT process not ready to receive commands

$ANDROID_HOME/build-tools/x.x.x/aapt
#=> aapt: cannot execute binary file: Exec format error

adb
#=> adb: cannot execute binary file: Exec format error

Note:

Docker Desktop for Mac and Docker Desktop for Windows are intended for development, rather than production. Modifying the storage driver on these platforms is not possible.
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
```
docker info | grep 'Storage Driver'
```
Check which filesystems are supported by the running host kernel
```
cat /proc/filesystems
```
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.
```
{
  "storage-driver": ""
}
```

Getting Started

# build the image
# set the working directory to the project's root directory first
docker build -t android-sdk android-sdk
# or you can also pass specific tool version as you wish (optional, while there is default version)
docker build --build-arg JDK_VERSION=<jdk_version> --build-arg GRADLE_VERSION=<gradle_version> --build-arg KOTLIN_VERSION=<kotlin_version> --build-arg ANDROID_SDK_VERSION=<android_sdk_version> -t android-sdk android-sdk
# or pull the image instead of building on your own
docker pull thyrlian/android-sdk

# below commands assume that you've pulled the image

# copy the pre-downloaded SDK to the mounted 'sdk' directory
docker run -it --rm -v $(pwd)/sdk:/sdk thyrlian/android-sdk bash -c 'cp -a $ANDROID_HOME/. /sdk'

# go to the 'sdk' directory on the host, update the SDK
# ONLY IF the host machine is the same target architecture as the container
# JDK required on the host
sdk/cmdline-tools/tools/bin/sdkmanager --update
# or install specific packages
sdk/cmdline-tools/tools/bin/sdkmanager "build-tools;x.y.z" "platforms;android-<api_level>" ...

# mount the updated SDK to container again
# if the host SDK directory is mounted to more than one container
# to avoid multiple containers writing to the SDK directory at the same time
# you should mount the SDK volume in read-only mode
docker run -it -v $(pwd)/sdk:/opt/android-sdk:ro thyrlian/android-sdk /bin/bash

# you can mount without read-only option, only if you need to update SDK inside container
docker run -it -v $(pwd)/sdk:/opt/android-sdk thyrlian/android-sdk /bin/bash

# to keep and reuse Gradle cache
docker run -it -v $(pwd)/sdk:/opt/android-sdk -v $(pwd)/gradle_caches:/root/.gradle/caches thyrlian/android-sdk /bin/bash

# to stop and remove container
# when the image was pulled from a registry
docker stop $(docker ps -aqf "ancestor=thyrlian/android-sdk") &> /dev/null && docker rm $(docker ps -aqf "ancestor=thyrlian/android-sdk") &> /dev/null
# when the image was built locally
docker stop $(docker ps -aqf "ancestor=android-sdk") &> /dev/null && docker rm $(docker ps -aqf "ancestor=android-sdk") &> /dev/null
# more flexible way - doesn't matter where the image comes from
docker stop $(docker ps -a | grep 'android-sdk' | awk '{ print $1 }') &> /dev/null && docker rm $(docker ps -a | grep 'android-sdk' | awk '{ print $1 }') &> /dev/null

Accepting Licenses

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.

SSH

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

# Put your `id_rsa.pub` under `android-sdk/accredited_keys` directory (as many as you want)

# Build an image, then an `authorized_keys` file will be composed automatically, based on the keys from `android-sdk/accredited_keys` directory
docker build -t android-sdk android-sdk

# Run a container
docker run -d -p 2222:22 -v $(pwd)/sdk:/opt/android-sdk:ro android-sdk

Mount authorized_keys file from the host to a container

# Make sure your local authorized_keys file has the correct permission set
chmod 600 $(pwd)/authorized_keys
sudo chown root:root authorized_keys

docker run -d -p 2222:22 -v $(pwd)/authorized_keys:/root/.ssh/authorized_keys thyrlian/android-sdk

Copy a local authorized_keys file to a container

# Create a local `authorized_keys` file, which contains the content from your `id_rsa.pub`
# Make sure your local authorized_keys file has the correct permission set
chmod 600 $(pwd)/authorized_keys

# Run a container
docker run -d -p 2222:22 -v $(pwd)/sdk:/opt/android-sdk:ro thyrlian/android-sdk

# Copy the just created local authorized_keys file to the running container
docker cp $(pwd)/authorized_keys `docker ps -aqf "ancestor=thyrlian/android-sdk"`:/root/.ssh/authorized_keys

# Set the proper owner and group for authorized_keys file
docker exec -it `docker ps -aqf "ancestor=thyrlian/android-sdk"` bash -c 'chown root:root /root/.ssh/authorized_keys'

That's it! Now it's up and running, you can ssh to it

ssh root@<container_ip_address> -p 2222

And, in case you need, you can still attach to the running container (not via ssh) by

docker exec -it <container_id> /bin/bash

VNC

Remote access to the container's desktop might be helpful if you plan to run emulator inside the container.

# pull the image with VNC support
docker pull thyrlian/android-sdk-vnc

# spin up a container with SSH
# won't work when spin up with interactive session, since the vncserver won't get launched
docker run -d -p 5901:5901 -p 2222:22 -v $(pwd)/sdk:/opt/android-sdk thyrlian/android-sdk-vnc

When the container is up and running, use your favorite VNC client to connect to it:

<container_ip_address>:5901
Password (with control): android
Password (view only): docker

# setup and launch emulator inside the container
# create a new Android Virtual Device
echo "no" | avdmanager create avd -n test -k "system-images;android-25;google_apis;armeabi-v7a"
# launch emulator
emulator -avd test -no-audio -no-boot-anim -accel on -gpu swiftshader_indirect &

For more details, please refer to Emulator section.

VNC client recommendation

macOS: Screen Sharing
Cross-Platform: VNC Viewer

NFS

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):

sudo apt-get update
sudo apt-get install -y nfs-kernel-server
sudo mkdir -p /var/nfs/android-sdk

# put the Android SDK under /var/nfs/android-sdk
# if you haven't got any, run below commands
sudo apt-get install -y wget zip
cd /var/nfs/android-sdk
sudo wget -q $(wget -q -O- 'https://developer.android.com/sdk' | grep -o "\"https://.*android.*tools.*linux.*\"" | sed "s/\"//g")
sudo unzip *tools*linux*.zip
sudo rm *tools*linux*.zip
sudo mkdir licenses
echo 8933bad161af4178b1185d1a37fbf41ea5269c55 | sudo tee licenses/android-sdk-license > /dev/null
echo 84831b9409646a918e30573bab4c9c91346d8abd | sudo tee licenses/android-sdk-preview-license > /dev/null
echo d975f751698a77b662f1254ddbeed3901e976f5a | sudo tee licenses/intel-android-extra-license > /dev/null

# configure and launch NFS service
sudo chown nobody:nogroup /var/nfs
echo "/var/nfs         *(rw,sync,no_subtree_check,no_root_squash)" | sudo tee --append /etc/exports > /dev/null
sudo exportfs -a
sudo service nfs-kernel-server start

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.