Build Android Automated Workflows (Part-1: Github Actions Primer)

For Android projects, It’s necessary to fully automated CI/CD pipelines that can make product quality and reduce the time it takes to deliver features to users.

In this blog, I’ll guide you through setting up similar workflows to optimize your own Android projects based on my experiences.

We’ll start by exploring the basics of GitHub Actions and quickly transition into hands-on examples of building automated workflows. You’ll learn how to perform important tasks like

• Code analysis, formatting,
• Unit and integration testing
• Preview Pull Request
• Deploying releases to the Google Play Store — all directly from GitHub

Whether you’re new to GitHub Actions or looking to refine your Android project workflows, this guide is here to help. Let’s dive in and unlock the full potential of CI/CD for your projects!

Although, I will not share basic introduction CI/CD, because most of the developers already understand these concepts.

GitHub Actions Primer

Before we started with building workflows our projects, it’s very important to understand some foundational concepts of GitHub Actions Primer.

In this section, I will explain each high level component of GitHub Actions and what they’re used for.

Top-level of GitHub Actions or workflows

Each of the workflow consists of YAML file that exists in the .github/workflows directory of your repository.

You can create multiple workflows in your repository, each designed to serve a specific purpose, like handling releases or managing pull requests.

Trigger

Every workflow requires a trigger to start it, which can be either manual or automatic. The trigger is specified in the .github/workflows using the on property.

If you want to trigger manually, we can define using workflow_dispatch syntax.

on:
  workflow_dispatch:

If you want to trigger automatically, we can run the workflow on the pull_request event.

on:
  pull_request:
    types:
      - opened
      - reopened
      - synchronize
      - ready_for_review

Each workflow requires at least one trigger assigned to it, and we can have multiple triggers defined within a workflow.

For example, we might want to allow manual triggers alongside an automatic trigger.

Jobs

A job is a group of tasks that run together, and jobs typically run in parallel unless configured otherwise.

Every workflow must have at least one job.

Each job should have a clear name to show its purpose in the actions console.

Good Practice → One job needs to focus on one responsibility.

For Example, One job could run unit tests , while another builds were checking the code style or run Android Lint etc...

If you want to use Jobs, you can trigger jobs in yaml. For example for danger,

jobs:
  danger:
    name: code review with Danger
    runs-on: ubuntu-latest  

For example for unit tests,

jobs:
  unitTest:
    name: Run unit tests
    runs-on: ubuntu-latest

Note: runs-on is Runner for the GitHub Actions.

Runner

A Runner is a virtual machine that executes the jobs defined within your workflow, and each job needs its own runner.

You can use GitHub’s provided runners or set up your own self-hosted ones. See details on Github Hosted Runners.

Standard GitHub-hosted runners for private repositories

Steps

Each job consists of a series of steps, which are the tasks it needs to perform.

Each steps can runs independently such as

• execute commands
• run actions
• setup tasks for the next steps

Jobs can have as many steps as needed, but if there are too many, it’s better to split them into separate jobs.

Good Practice → Give each step a clear name to easily understand its purpose in the actions console.

If you want to trigger, we can run the workflow on the steps inside the jobs.

steps:
  - uses: actions/checkout@v2
  - name: set up JDK      
    uses: actions/setup-java@v3
    with:
      distribution: 'temurin'
      java-version: '17'
      cache: 'gradle'
  - uses: actions/setup-node@v1
    with:
      node-version: '12'
  - name: Setup Android SDK
    uses: android-actions/setup-android@v2.0.8

Actions

An action was designed to handle specific tasks within a step.

Steps can use one, many, or no actions at all — they’re optional.

Actions are great for simplifying repetitive tasks and can be reused across your workflows or shared with others.

    - name: Set up JDK
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: '17'
    - name: Run Lint
      run: bash ./gradlew lint

You can create your own actions or use ones shared by others.

However, it’s very important to review any actions plan to use from third party actions form market place, considering factors like security and whether the action is actively maintained.

Wrapping Up

I will explain how can we code analysis, formatting, unit and integration testing, and even deploying releases to the Google Play Store with these GitHub actions.

If you want to learn more about the anatomy of GitHub Actions, please check out the official documentation over at https://docs.github.com/en/actions.

See you next time 😉.