Android Emulator

Tenki Linux x64 Runners support KVM nested virtualization, so they can run Android emulator-based CI, Espresso, instrumented tests, screenshot tests, Detox, and similar UI-test workloads.

Nested virtualization (KVM)

Tenki x64 runners support KVM nested virtualization, so your jobs can boot Android emulators using the standard Android SDK system images, including:

• system-images;android-34;google_apis;x86_64
• Older API levels (29 to 33) for legacy test matrices
• Google Play variants of the above

End-to-end UI tests (Espresso, instrumented JUnit, screenshot tests) run on the booted emulator within the runner.

Example workflow

The workflow below uses reactivecircus/android-emulator-runner on a Tenki Linux runner. The only line that differs from a GitHub-hosted runner workflow is runs-on.

jobs:
  ui-tests:
    runs-on: tenki-standard-large-8c-16g
    steps:
      - uses: actions/checkout@v4

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

      - name: Cache AVD
        uses: actions/cache@v4
        with:
          path: |
            ~/.android/avd/*
            ~/.android/adb*
          key: avd-android-34

      - name: Run instrumented tests
        uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 34
          target: google_apis
          arch: x86_64
          script: ./gradlew connectedCheck

Picking a runner size

Android emulator workloads are memory-hungry and benefit from more cores during APK compilation. Recommended starting points:

See Which Runner to use? for general sizing guidance.

Caching the emulator

Use actions/cache (backed by Tenki's hosted Actions cache) to persist the AVD between runs, as in the workflow above. The first cold boot of a new API level takes a few minutes; subsequent runs with a warm AVD are much faster.

If the emulator fails to boot, see Troubleshooting for the next checks and support path.