CI/CD with GitHub Actions

A CI workflow’s job is to answer, automatically and consistently, "does this change still build, pass lint and pass tests" — before a human reviews the pull request and before it merges. The workflow below runs on every push to main, every pull request targeting main, and manually via workflow_dispatch; it checks out the code, enables hardware-accelerated emulation, sets up the JDK, restores Gradle’s caches, runs lint/unit/instrumented tests across a small matrix, publishes test results and coverage, scans the code with SonarCloud, generates and deploys API documentation, and uploads build artifacts — cancelling any older run still in flight for the same branch or pull request.

See reactivecircus/android-emulator-runner — README.

Section by section:

Gradle’s own caching mechanism (org.gradle.caching=true in gradle.properties, discussed in Project Structure, Gradle and Build Variants) complements `setup-gradle’s cache restore: one caches task outputs across the whole team and every CI run, the other caches the dependency/build-cache directories for this workflow’s own runners.

Releasing the app itself is a separate workflow, triggered by publishing a GitHub release or pushing a tag rather than by every push, since it performs an irreversible action (uploading a new version to a Play Console track). It decodes a keystore from a repository secret, builds a signed release bundle, and uploads it to Google Play.

See r0adkll/upload-google-play — README.

Never place base64-encoded key material, the raw keystore, passwords or a service-account JSON file in the workflow itself or in a committed file — every one of them above is read from a repository or environment secret (secrets.KEYSTORE_BASE64, secrets.KEYSTORE_PASSWORD, secrets.KEY_ALIAS, secrets.KEY_PASSWORD, secrets.PLAY_SERVICE_ACCOUNT_JSON) and referenced only by name. The keystore itself is produced by base64-encoding the .jks/.keystore file once, locally, and pasting that text into a GitHub secret through the repository’s Settings UI or gh secret set — the workflow only ever decodes it back to a file in the ephemeral runner’s temporary directory (runner.temp, outside the checkout), which the final step removes. app/build.gradle.kts’s `signingConfigs block falls back to exactly these four environment variables — KEYSTORE_PATH (an absolute path here, resolved with rootProject.file(…​)), KEYSTORE_PASSWORD, KEY_ALIAS and KEY_PASSWORD — whenever keystore.properties is absent, as it is on a CI runner; see Building, Signing and Preparing a Release. If the names on the two sides ever drift apart, bundleRelease fails on CI with an incomplete signing configuration.

r0adkll/upload-google-play@v1 wraps the Play Developer API: serviceAccountJsonPlainText (or serviceAccountJson, a path to a file) authenticates as a service account with API access to the Play Console (configured once in Play Console → Setup → API access), packageName identifies the app, releaseFiles points at the signed .aab and track selects which Play track receives it (internal, alpha, beta or production). Promoting a release from one track to the next — for example internal to production after manual QA — is a second run of the same action with a different track (and, optionally, userFraction for a staged rollout), or the same manual promotion done from the Play Console UI; inAppUpdatePriority sets the priority value the Play In-App Update API reports to installed clients, letting the app decide whether to nudge users toward an update. The Gradle Play Publisher plugin (com.github.triplet.play) is a Gradle-native alternative to this action — it drives the same Play Developer API through Gradle tasks (./gradlew publishBundle, promoteArtifact) instead of a separate workflow step, which some teams prefer when they want the publish step invokable identically from a developer’s machine and from CI.

Publishing a library, rather than an app, uses release-triggered publishing to the Central Publisher Portal covered in Building and Publishing Android Libraries to Maven Central. The workflow below is the real irurueta-android-glutils publish.yml, modernized to checkout@v7/setup-java@v6:

See Gradle Maven Publish Plugin — Maven Central.

on.release.types: [ released ] fires only when a GitHub release is published (not on a draft or pre-release), so publishing a new library version is an explicit, human-triggered action: cut a release on GitHub and this workflow uploads it to Maven Central. ./gradlew :lib:assembleRelease builds the release AAR; ./gradlew lib:publishAndReleaseToMavenCentral --no-configuration-cache (the vanniktech com.vanniktech.maven.publish plugin task discussed in the Maven Central page) both uploads the artifacts and triggers their automatic release from the Central Publisher Portal in one step — --no-configuration-cache works around a known incompatibility between that plugin’s signing tasks and Gradle’s configuration cache. The five ORG_GRADLE_PROJECT_* environment variables are Gradle’s convention for injecting project properties from the environment: ORG_GRADLE_PROJECT_foo becomes the Gradle property foo, so ORG_GRADLE_PROJECT_mavenCentralUsername supplies the plugin’s mavenCentralUsername property without that value ever appearing in a gradle.properties file that could be committed by mistake. Each one is read here only from a matching repository secret (secrets.MAVEN_CENTRAL_USERNAME, secrets.MAVEN_CENTRAL_PASSWORD, secrets.SIGNING_MEMORY_KEY, secrets.SIGNING_MEMORY_KEY_ID, secrets.SIGNING_IN_MEMORY_KEY_PASSWORD) — never inlined.

Dependabot opens automated pull requests when a dependency has a newer version available. A minimal configuration covering both Gradle dependencies and the GitHub Actions used above:

See GitHub Docs — Dependabot options reference.

The gradle ecosystem entry watches build.gradle.kts/version-catalog declarations and opens a pull request per outdated dependency (or a grouped one, with groups:); the github-actions entry does the same for the uses: references in every workflow file under .github/workflows/, which is how action versions such as the ones listed at the top of this page stay current without a manual audit.

Secrets hygiene matters more on CI than almost anywhere else in the pipeline, because a workflow’s secrets are the credentials capable of publishing a release, signing an app, or pushing to gh-pages:

Gradle Managed Devices are an alternative to reactivecircus/android-emulator-runner for instrumented tests in CI: instead of the action booting and tearing down an emulator, a managedDevices block in build.gradle.kts declares one or more device definitions and Gradle itself provisions, boots, runs connectedCheck against, and tears down the corresponding virtual devices as part of the Gradle task graph, with results cached like any other Gradle output. It trades the action’s simplicity for devices that behave identically whether run locally or in CI and integrate with Gradle’s own caching, at the cost of managing device definitions in the build script rather than the workflow YAML.

Firebase App Distribution and Firebase Test Lab are complementary Firebase-hosted CI services worth knowing about even without a deep dive here: App Distribution pushes a build to a list of testers' devices outside the Play Console’s testing tracks (useful for QA before a Play release even exists), and Test Lab — as already introduced in Instrumented and UI Testing — runs the instrumented test APK against a much larger matrix of real and virtual devices than a CI runner’s own emulators can practically cover. Both are typically wired into a workflow as an additional job or step using their respective GitHub Actions, gated the same way the release jobs above are gated (a tag, a release event, or a manual workflow_dispatch).

A pull request runs the CI workflow; once it merges to main, API documentation is republished and the change is included in the next release. Publishing a GitHub release is the fork in the pipeline: an app release workflow signs and uploads a bundle to Google Play (promoted from internal toward production over time), while a library publish workflow builds and releases the artifact to Maven Central — the two downstream targets never share a workflow because they sign, package and publish to entirely different destinations.