Introduction to CI/CD and GitHub Actions for Android Projects

The article begins by revisiting the concepts of CI/CD and automated builds, then defines CI (continuous integration) as the practice of frequently committing code to a shared repository to catch errors early, and CD (continuous deployment) as the automated release of software updates.

It introduces GitHub as a cloud‑based code hosting platform and explains that GitHub Actions is a CI/CD service that can automate building, testing, and deploying projects, as well as respond to other repository events such as issue creation.

In the practical section, the author assumes the reader already has a GitHub account and a repository. The steps to create a workflow are described: navigate to the repository’s Actions tab, select a template (e.g., Android CI), and configure the workflow file located at .github/workflows/android.yml .

The sample workflow file is presented:

name: Android CI

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: set up JDK 11
      uses: actions/setup-java@v4
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: gradle
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      run: ./gradlew build

The workflow consists of the name (workflow identifier), on (trigger events such as push, pull_request, or schedule), and jobs (individual tasks). Each job runs on a specified runner ( runs-on ) and contains ordered steps that may use actions ( uses ) or execute shell commands ( run ).

Key step explanations are provided: actions/checkout@v4 checks out the code, the JDK setup step defines the Java version (modifiable to JDK 17, for example), chmod +x gradlew grants execution permission, and ./gradlew build builds the project.

After committing the workflow, GitHub automatically runs it; screenshots illustrate the workflow execution and log output, noting that the first run may take longer due to environment setup and lack of caching.

The article also shows how to view build logs, emphasizing the importance of the build with gradle section and the repository checkout logs for troubleshooting.

Customization options are discussed, such as adding a Gradle cache step:

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

adding a Lint check:

- name: Run Lint
  run: ./gradlew lint

and packaging and publishing an APK:

- name: Build APK
  run: ./gradlew assembleRelease

- name: Upload Release APK
  uses: actions/upload-artifact@v2
  with:
    name: app-release.apk
    path: app/build/outputs/apk/release/app-release.apk

Environment variables can be set via GitHub Secrets and accessed in the workflow, for example to handle signing keys:

- name: Sign and release
  env:
    KEYSTORE_FILE: ${{ secrets.KEYSTORE_FILE }}
    KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
    KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
    KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}
  run: |
    echo $KEYSTORE_FILE | base64 --decode > keystore.jks
    ./gradlew signingReport
    ./gradlew bundleRelease

Finally, the article concludes that understanding CI/CD fundamentals and using GitHub Actions enables automated building and deployment of Android projects, improving development efficiency.