DEV Community: Iván Valdés

Automating Building Android APKs with GitHub Actions

Iván Valdés — Sun, 01 Oct 2023 20:39:47 +0000

As part of my goal to decrease my smartphone addiction, I recently bought a Unihertz Jelly phone, which could be a good compromise between a smartphone and a dumbphone. The phone has a multi-purpose function button. You can assign it to specific pre-defined actions or launch any application. As I regularly use the phone screen in grayscale mode, I decided to assign the button to an application that would toggle this mode. I searched and couldn't find a simple app to toggle it when launching. So I decided to write my own. However, this previous background could be a post on its own.

As I've been trying to leverage GitHub actions for manual tasks, I searched GitHub and found many actions that could do this for me. I tried with a couple of them, and they didn't work. One of the issues is that the actions are using obsolete dependencies, and I spent way more time trying to make them run than I wanted.

I decided to make it work without a pre-built action and write all of the required steps in a GitHub workflow, which, in the end, was very simple. Here's the action. I will do a walk-through so you can use it in your projects.

name: Release APK

on:
  push:
    tags:
      - '*'

This workflow will run when pushing a tag to a repository.

jobs:
  Gradle:
    runs-on: ubuntu-latest
    steps:
    - name: checkout code
      uses: actions/checkout@v3

This is the standard step to checkout the code. It can run with the latest checkout action (v3).

    - name: setup jdk
      uses: actions/setup-java@v3
      with:
        java-version: 17
        distribution: 'temurin'

Then, we need to set up the JDK. Again, using the latest setup-java action (v3). I set the Java version to 17, which is the one that my Android Project uses. You can adjust the distribution, too. Refer to setup-javas documentation.

Now, to sign the released APK, we'll need to load the Keystore (you can read how to generate it on Android's official documentation).

   - name: Load keystore
      run: |
        echo "${{ secrets.KEYSTORE_FILE_CONTENTS }}" | base64 -d > keystore.jks && \

The secret KEYSTORE_FILE_CONTENTS, contains the base64 encoded content of the keystore.jks file you generated. You can get the text for the secret by running cat keystore.jks | base64 -w0.

    cat <<EOL > local.properties
        storeFilePath=$PWD/keystore.jks
        storePassword=${{ secrets.RELEASE_STORE_PASSWORD }}
        keyAlias=${{ secrets.RELEASE_KEY_ALIAS }}
        keyPassword=${{ secrets.RELEASE_KEY_PASSWORD }}
        EOL

The rest of the secrets are the ones you entered when configuring your keystore.

Next, we'll build the APK:

    - name: Build Release APK
      run: ./gradlew assembleRelease
      env:
        GRADLE_USER_HOME: ./gradle-config

And set the current directory as a safe repository, as this is a known issue with actions/checkout@v3. And because we'll later use github-cli to do the release, I didn't want it to complain that it couldn't read the repository.

    - name: Set current directory as a safe repository
      run: git config --global --add safe.directory /github/workspace
    - uses: ButterCam/setup-github-cli@master

Finally, release the APK and upload it to the repository's releases page.

    - name: Release using github cli
      run: gh release create ${GITHUB_REF##*/} ./app/build/outputs/apk/release/**.apk
      env:
       GITHUB_TOKEN: ${{ secrets.TOKEN }}

You'll need to generate a token with repo access for this to work. For some reason, using the default repository's GITHUB_TOKEN won't work.

And here's the full YAML in case you want to copy-paste it. You can also check it in my repository.

name: Release APK

on:
  push:
    tags:
      - '*'
jobs:
  Release:
    runs-on: ubuntu-latest
    steps:
    - name: checkout code
      uses: actions/checkout@v3
    - name: setup jdk
      uses: actions/setup-java@v3
      with:
        java-version: 17
        distribution: 'temurin'
    - name: Load keystore
      run: |
        echo "${{ secrets.KEYSTORE_FILE_CONTENTS }}" | base64 -d > keystore.jks && \
        cat <<EOL > local.properties
        storeFilePath=$PWD/keystore.jks
        storePassword=${{ secrets.RELEASE_STORE_PASSWORD }}
        keyAlias=${{ secrets.RELEASE_KEY_ALIAS }}
        keyPassword=${{ secrets.RELEASE_KEY_PASSWORD }}
        EOL
    - name: Build Release APK
      run: ./gradlew assembleRelease
      env:
        GRADLE_USER_HOME: ./gradle-config
    - name: Set current directory as a safe repository
      run: git config --global --add safe.directory /github/workspace
    - uses: ButterCam/setup-github-cli@master
    - name: Release using github cli
      run: gh release create ${GITHUB_REF##*/} ./app/build/outputs/apk/release/**.apk
      env:
       GITHUB_TOKEN: ${{ secrets.TOKEN }}

There's still one thing that needs configuration to sign the APK properly. You'll need to edit your app/build.gradle.kts file so we can feed the properties from GitHub secrets to the assmbleRelease task. Kudos to Willi Metzel's Stack Overflow answer. Inside android in app/build.gradle.kts add:

    signingConfigs {
        create("release") {
            val properties = Properties().apply {
                load(File("local.properties").reader())
            }
            storeFile = File(properties.getProperty("storeFilePath"))
            storePassword = properties.getProperty("storePassword")
            keyPassword = properties.getProperty("keyPassword")
            keyAlias = properties.getProperty("keyAlias")
        }
    }

Then, add signingConfig = signingConfigs.getByName("release") to release inside buildTypes. It should look something like:

   buildTypes {
        release {
            isMinifyEnabled = false
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            signingConfig = signingConfigs.getByName("release")
        }
    }

See here for a complete reference to my app/build.gradle.kts.

Credits to r0adkll for his previous work; without it, building this would have been more difficult.

You can follow me at GitHub (@ivanvc). And check the repository (and source code for my grayscale switching app) if you're interested.

Publishing Alpine Linux packages using GitHub actions

Iván Valdés — Thu, 17 Aug 2023 18:09:57 +0000

Not so long ago, I decided to install Alpine Linux on some compact laptops I use when I'm out and about. One of them is an 11" 2015 Macbook Air. I have often installed Linux on Macbooks, but the experience could be more optimal, as there are many issues with the firmware support, as most of the time is closed. Alpine would be an excellent fit for this old Macbook, as the RAM and CPU specs are fundamental, and any other modern OS (macOS or other Linux distribution) would make it slow and unusable.

However, there were two firmware drivers that I couldn't find for this Macbook:

The wireless network card (broadcom-wl)
The FaceTime HD webcam (facetimehd)

To make this portable laptop something I could use when I'm not at home and to be able to work and take video calls using Zoom. I needed these two to work. So, with the deprecation of the non-free aports repository, I needed to do it from scratch if I wanted to build them. Given that the laptop has limited resources, I didn't want to create the apks on it, so I made them on my main computer and installed the packages from the .apk files. This worked, but then I wanted to host the packages somewhere, so I could install them by adding a new repository.

After searching GitHub, I found an action that builds the packages, but it stops there. It doesn't publish them anywhere. So, I wrote a GitHub action to release Alpine Linux APKs to its repository page. I wanted to build an index page for the repository's packages, so I wrote tpl (interested on reading about it? check my previous post) to make this easy. And this is what it looks like:

Given that Alpine Linux doesn't keep previous versions of the packages; at work, we needed to lock some packages (i.e., Docker) to an old version. I thought this would also be an easy way to build and publish these packages.

Find the documentation at the repository and GitHub's marketplace. Pull Requests and new features are welcome.

Bringing Go Templates everywhere

Iván Valdés — Sat, 05 Aug 2023 06:20:42 +0000

As developers, we often copy and paste code, configurations, and templates between projects. This duplication leads to tech debt and missed optimization opportunities. That's why I created tpl - a simple, flexible templating tool to help developers standardize and reuse elements across their stack.

There are many instances in which I could use a gotemplate to avoid a repetitive task. I searched for a simple tool (ideally a binary) that would help to achieve running gotemplates in an arbitrary file (i.e., I love Helm templating, but it's limited to YAML files), however, after doing a GitHub search. I couldn't find what I wanted.

So, as I was working on a project that needed what I wanted. I paused that other project and decided to run a simple gotemplate wrapper.

Ideally, I wanted it to be not opinionated, so it supports reading input files from stdin, a file, or receiving it as an argument. However, a simple gotemplate with an environment would be helpful. So, it supports JSON, TOML, and YAML inputs for the environment. It tries to guess the format for the given environment, but it's also possible to force the format (in case it's wrongly parsed using another format). You can specify the environment inline as an argument, or using a file (if the first character is @, similar to curl).

Here are a some samples on how to use tpl.

JSON environment from GitHub's API using stdin

There are many instances in which I want to run a template using an external resource (i.e., an HTTP API). I could do this using bash and jq. But doing it with a gotemplate is way easier. Note that, in this case, the response is a JSON array. Like other tools I tried, it doesn't break, which would, as they expected to, be a JSON object. You need to handle . in the template as an array.

TOML environment building an index page using an input file

In my recent project (see my post on Publishing Alpine Linux Packages using GitHub Actions), I wanted to build index page(s). So, a TOML input is an easy way to pass a list of files.

YAML environment input defining a Terraform module

I wrote mleh years ago when I was trying to generate a Helm template with a Terraform output. Of course, Helm didn't like the format, which didn't work. While mleh is helpful for complex templates (i.e., it follows Helm's practices ignoring files that start with an underscore, and you can specify a values.yaml file as environment), there are some instances in which I need something more straightforward.

So, if you want to give tpl a try, you can:

Install it by downloading the latest binary from its GitHub releases page

Install it using Go:

$ go install github.com/ivanvc/tpl@latest

Use it with Docker:

$ docker run --rm ivan/tpl:latest --help

Or, you could use it in your Dockerfile

COPY --from=ivan/tpl:latest /bin/tpl /bin