Skip to content

raatiniemi/docker-android-environment

Repository files navigation

android-environment

GPLv3 license Pipeline status

Docker container image for building Android applications in an CI/CD pipeline, the container images either use JDK 8, JDK 11, or JDK 17 as the base image.

All images include both:

  • Android tools SDK
  • Platform tools

Default behaviour require you as a user to install the Android API version that your application needs. However, there are images available with an Android API preinstalled which will reduce build times, see Usage.

Usage

The image is available via Docker Hub using the raatiniemi/android-environment name, see available tags.

Naming convention

The tags for images include explicit versions, i.e. which JDK version should be used and for images with Android API preinstalled the API version is included.

  • jdk-17-latest — With only required components and JDK 17.
  • jdk-17-android-28-latest — With Android API 28 and JDK 17.
  • jdk-17-android-29-latest — With Android API 29 and JDK 17.
  • jdk-17-android-30-latest — With Android API 30 and JDK 17.
  • jdk-17-android-31-latest — With Android API 31 and JDK 17.
  • jdk-17-android-32-latest — With Android API 32 and JDK 17.
  • jdk-17-android-33-latest — With Android API 33 and JDK 17.
  • jdk-17-android-34-latest — With Android API 34 and JDK 17.
  • jdk-11-latest — With only required components and JDK 11.
  • jdk-11-android-28-latest — With Android API 28 and JDK 11.
  • jdk-11-android-29-latest — With Android API 29 and JDK 11.
  • jdk-11-android-30-latest — With Android API 30 and JDK 11.
  • jdk-11-android-31-latest — With Android API 31 and JDK 11.
  • jdk-11-android-32-latest — With Android API 32 and JDK 11.
  • jdk-11-android-33-latest — With Android API 33 and JDK 11.
  • jdk-11-android-34-latest — With Android API 34 and JDK 11.
  • jdk-8-latest — With only required components and JDK 8.
  • jdk-8-android-28-latest — With Android API 28 and JDK 8.
  • jdk-8-android-29-latest — With Android API 29 and JDK 8.
  • jdk-8-android-30-latest — With Android API 30 and JDK 8.
  • jdk-8-android-31-latest — With Android API 31 and JDK 8.
  • jdk-8-android-32-latest — With Android API 32 and JDK 8.
  • jdk-8-android-33-latest — With Android API 33 and JDK 8.
  • jdk-8-android-34-latest — With Android API 34 and JDK 8.

Use of the latest tag is not recommended as it do not specify the version of JDK to use, it currently uses JDK 8 but will be migrated to use JDK 11 in the future.

Install additional Android tools

In order to install additional Android tools the use of sdkmanager is recommended, and when using the sdkmanager the license must be accepted.

The following is a sample script for installing the build-tools aswell as a version of the Android API.

function accept_license_and_install {
  yes | sdkmanager $1 1>/dev/null;
  if [ $? -ne 0 ]; then
    echo "Failed to accept license and install ${1}";
    exit 1;
  fi
}

accept_license_and_install "build-tools;27.0.3";
accept_license_and_install "platforms;android-27";

The build tools are not installed by default since they are installed when the gradlew command is executed.

GitLab CI

If you're using GitLab CI to build your application you can include the GitLab CI job template. The template includes a job that can be used as a base when building and testing where the Android SDK is required.

The template is based on usage in Worker. If your use case differ, feel free to open an issue to start a discussion.

Also, if you depend on the template it might be a good idea to lock it to a specific revision to reduce the possibility of breakage.

.in-android-environment

The .in-android-environment job uses both before_script and after_script to setup and tear down the environment, i.e. only script is available for your operations. Also, it's using a docker runner tag to target available runner(s).

Since Android application needs to be signed you are required to expose the keystore in an base64 format using the environment variable KEYSTORE_BASE64. It's recommended to use the GitLab CI variables or some other means of populating the environment variables, do not include the keystore in your .gitlab-ci.yml as it will be included in your git history.