Android Development
Updated 8 days ago | GitHub

Setting up Travis CI

Overview

⚠️ Heads up: Travis CI is no longer free for most open source projects — in November 2020 it moved OSS builds to a limited trial-credit model, and the original travis-ci.org platform was shut down in June 2021. Most Android open-source projects now use GitHub Actions for CI instead, and that is the approach this page covers. A short historical Travis CI reference remains at the bottom.

Continuous integration (CI) runs your unit and instrumentation tests against every push and pull request, so regressions surface before they land. For projects hosted on GitHub, GitHub Actions is the built-in CI service: it is free for public repositories, requires no separate sign-up, and has first-class support for Gradle and the Android SDK (the SDK comes preinstalled on GitHub-hosted Ubuntu runners, so there is no SDK component list to manage like Travis required).

Setting up GitHub Actions

Workflows live in your repository under .github/workflows/. Create a file such as .github/workflows/android.yml:

name: Android CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-java@v5
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v6

      - name: Build and run unit tests
        run: ./gradlew build

The pieces:

  • actions/setup-java installs the JDK — temurin 17 satisfies the Java requirement of current Android Gradle Plugin versions.
  • gradle/actions/setup-gradle validates the Gradle wrapper against known checksums and caches the Gradle user home between runs, which substantially speeds up repeat builds.
  • ./gradlew build compiles the app and runs lint plus local unit tests. Reports land under app/build/reports/.

See GitHub’s Building and testing Java with Gradle guide for the canonical version of this workflow.

Running instrumentation tests on an emulator

Instrumentation tests (see UI Testing with Espresso) need a device. On GitHub-hosted Linux runners the community-standard approach is the android-emulator-runner action, which boots a hardware-accelerated emulator via KVM:

jobs:
  instrumentation-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Enable KVM
        run: |
          echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' | sudo tee /etc/udev/rules.d/99-kvm4all.rules
          sudo udevadm control --reload-rules
          sudo udevadm trigger --name-match=kvm

      - uses: actions/setup-java@v5
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Run instrumentation tests
        uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 29
          script: ./gradlew connectedCheck

The action’s README recommends Ubuntu runners for emulator jobs — they are “2-3 times faster than the macOS ones which are also a lot more expensive.”

Troubleshooting

  • Out-of-memory failures: large dependency graphs can exhaust the default Gradle JVM heap. Raise it in gradle.properties (org.gradle.jvmargs=-Xmx4g) rather than in the workflow, so local and CI builds behave the same.
  • Play Services bloat: if you use Google Play Services, depend on the specific split artifacts you need (e.g. com.google.android.gms:play-services-maps) instead of the monolithic play-services artifact — this keeps both build times and method counts down.
  • Inspecting lint results: upload app/build/reports/ as a workflow artifact, or view the lint summary directly in the failed step’s log.

Historical reference: Travis CI setup

The configuration below is preserved for teams maintaining a legacy .travis.yml. It targets tooling that has since been removed (SDK components pinned to android-27 / build-tools-27.0.3, oraclejdk8, and workarounds like dexOptions { preDexLibraries }, which was removed entirely in Android Gradle Plugin 8.0). Do not copy it into a new project.

Travis CI was configured through a .travis.yml file in the repository root, which named the SDK components to install and the Gradle command to run:

language: android
android:
  components:
    - tools # to get the new `repository-11.xml`
    - tools # see https://github.com/travis-ci/travis-ci/issues/6040#issuecomment-219367943)
    - platform-tools
    - build-tools-27.0.3
    - android-27
before_install:
  - yes | sdkmanager "platforms;android-27"
script:
   - ./gradlew build connectedCheck

Builds signed in with GitHub credentials at travis-ci.com, and private repositories required a paid plan. The Travis Android docs describe the remaining options for teams still on the platform.