Android Gradle build slow in GitHub Actions: Gradle cache, build cache, heap and cores

An Android Gradle build in GitHub Actions is slow for four reasons that stack. Each job is a new VM, so Gradle User Home (~/.gradle: dependencies, the wrapper's Gradle distribution, the local build cache) starts empty. Gradle's build cache is off until you set org.gradle.caching=true. Gradle's heap defaults to 512 MB (-Xmx512m), and Android's docs say to raise it to 4–8 GB when garbage collection takes more than 15% of the build. And a private repository's ubuntu-latest has 2 CPUs and 8 GB. Fix them in that order: cache Gradle User Home with gradle/actions/setup-gradle, turn on the build cache and parallel execution, raise the heap, then give the build more cores and memory. The last two are the machine. A runner that keeps ~/.gradle on its disk between jobs skips the cache restore as well.

Skipbox runs your jobs on your account's own machine, which keeps Gradle User Home, the JDKs and Docker's layers between jobs. Change one line, runs-on: skipbox, for a flat $39 a month with unlimited minutes, or skipbox-8x16 for 8 vCPU and 16 GB.

1. Cache Gradle User Home

setup-gradle caches the parts of Gradle User Home that help the next build: downloaded dependencies, wrapper distributions and the local build cache.

- uses: actions/setup-java@v5
  with:
    distribution: temurin
    java-version: 17
- uses: gradle/actions/setup-gradle@v6
- run: ./gradlew assembleDebug

Three things in its docs decide how much it helps:

• Only the default branch writes. By default, jobs on other branches and pull requests read the cache and don't save it, so a long-lived branch keeps restoring what main last saved.
• Every run writes a new entry, per job and OS, and each counts toward GitHub's 10 GB per repository.
• The default cache provider is free for public repositories and in Free Preview for private ones. cache-provider: basic is the MIT-licensed one.

2. Turn on the build cache and parallel execution

From Gradle's performance guide, in gradle.properties:

org.gradle.caching=true
org.gradle.parallel=true
org.gradle.configuration-cache=true

• org.gradle.caching=true. "By default, Gradle does not use the Build Cache." With it on, a task whose inputs haven't changed comes FROM-CACHE. Across CI jobs that needs the local build cache in Gradle User Home to survive, or a remote build cache.
• org.gradle.parallel=true runs tasks of different modules at once. It needs cores to run them on.
• The configuration cache skips the configuration phase when the build scripts haven't changed. Android's build-speed guide recommends it too.

Android's guide adds two project settings that cut work: non-transitive R classes, and turning off Jetifier when no dependency still needs it.

3. Give Gradle a heap that fits the build

Gradle's default JVM arguments are -Xmx512m -XX:MaxMetaspaceSize=384m (build environment). Android's guide says to raise the heap to 4, 6 or 8 GB if garbage collection takes more than 15% of the build time (the Build Analyzer shows it), and to try the parallel collector:

org.gradle.jvmargs=-Xmx6g -XX:+UseParallelGC

On a private repository's ubuntu-latest, 6 GB of heap is three quarters of the machine's 8 GB, with every other process of the build and the OS still to fit. When the machine runs out, Linux stops the build and the job ends with exit code 137. 16 GB, as on Skipbox M, leaves room.

4. Give the build more cores

With parallel execution on, Gradle runs independent modules' tasks at once. A private repository's ubuntu-latest has 2 CPUs (GitHub-hosted runners). GitHub's larger runners have more, for organizations on GitHub Team or Enterprise Cloud, per minute: 8 cores and 32 GB cost $0.022 a minute.

The daemon on CI

Gradle's guide: on CI, "long-lived agents benefit" from the daemon, "but short-lived ones may not". A GitHub-hosted job is short-lived. So is a Skipbox job for the daemon: every process is stopped after each job, so the next job starts a new one. What carries over is on the disk.

What each fix costs on GitHub's runners

• setup-gradle's cache is a download and an unpack at the start of each job, and an upload at the end of each default-branch job. A pull request reads what main saved, not its own last run.
• A remote build cache is another server to run, and every hit crosses the network.
• More cores and memory is a larger runner, on GitHub Team or Enterprise Cloud.

Skipbox keeps Gradle User Home

Each plan comes with your account's own machine, kept between jobs:

• ~/.gradle/caches stays: dependencies, transforms and the local build cache. With org.gradle.caching=true, a task whose inputs are unchanged comes FROM-CACHE on the next job, a pull request's job included.
• The wrapper's Gradle distribution stays in ~/.gradle/wrapper, and so do the JDKs setup-java installed and Docker's images and layers.
• setup-gradle steps aside. When ~/.gradle/caches already exists, setup-gradle by default doesn't overwrite it, and the job summary says "Caching for Gradle actions was disabled due to pre-existing Gradle User Home". The same workflow still runs on GitHub's runners.
• No Android SDK in the image. GitHub's ubuntu-latest ships one; on Skipbox, add android-actions/setup-android.
• More cores and memory by label, at a flat price. Minutes are unlimited.

At least 7× GitHub's cache room on S. A job picks its size by label:

At 20,000 minutes a month, GitHub's 4-core runner is $222 against $39 for S, and its 8-core runner $422 against $79 for M. GitHub's figures are after GitHub Team's included usage.

Moving is one line

jobs:
  build:
    runs-on: skipbox-8x16 # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v5
        with:
          distribution: temurin
          java-version: 17
      - uses: android-actions/setup-android@v4
      - uses: gradle/actions/setup-gradle@v6
      - run: ./gradlew assembleDebug testDebugUnitTest

skipbox-8x16 runs on an M plan; the trial runs runs-on: skipbox.

1. Sign in to Skipbox with GitHub.
2. Install the Skipbox GitHub App and pick the repositories.
3. Change runs-on and push.

Security

• The machine is your account's alone. No other company's jobs run on it.
• After every job, the runner's credentials, processes and containers are wiped, and so are the credential files in the home directory. Clean every job gives each job a fresh machine instead.
• Code from people without write access (such as pull requests from forks) runs on a fresh VM that reads your caches but can't change them.

The details are in how jobs are isolated.

Try it on the Android build

The trial is free for 7 days or 3,000 job-minutes, whichever comes first, and takes no card. Move the build job to runs-on: skipbox, run it twice, and put the second run's task outcomes (FROM-CACHE, UP-TO-DATE) next to GitHub's.

Updated November 13, 2026