Continuous Delivery in Flutter on GitHub Actions - Android Release

 What if we want to distribute the apps?

We can create a new workflow that allows us to push a tag on the master branch to automatically distribute the apps to the shops. Sounds great, doesn't it? Let's get on with it.

Android Distribution

The first thing we need to do is to create a secret with the contents of the Android store certificate. To do this we will use the action timheuer/base64-to-file which will allow us to maintain file from a base64-encoded string.

As you may already know, to distribute your Android applications we must sign them before uploading them to the store. This is the first thing we are going to do.

We will encode the content of the JKS file containing our signing certificate in base64. One way to do this is to use the command cat key.jks | base64' from the terminal. This will return a jumble of letters and numbers to be added to a new secret on GitHub (If this doesn't ring a bell I suggest you read the following tutorial where I explained how to do this). In my case I have called it ANDROID_KEYSTORE_BASE64.

Now we must add the keys storePassword, keyPassword and keyAlias as secrets to compose the key.properties file.

After that, we will need to configure API access in the Google Play console. This consists of creating a Google Cloud service with distribution permissions so that from the GitHub Actions container we can publish the Android App Bundle of our application.

In the Google Play console, go to Setup and then go to API Access.

The section we are interested in is called Service accounts. We are interested in creating a service that has enough permissions to publish our application by communicating from GitHub Actions. The section we are interested in is called Service accounts. We are interested in creating a service that has enough permissions to publish our application by communicating from GitHub Actions. At this point we will see that there are no service accounts associated. We will see a roulette of settings within Service account to create an account associated with this project within Google Cloud.

When you click on either link, the Google Cloud Console should have opened. Inside you will have to create a new service associated with your project or application. Click on CREATE SERVICE ACCOUNT

Fill in all the data on the screen. When we introduce a name to the service, an ID associated with the name is automatically created, which we can change or leave as it is offered.

Once we have created it and given permissions to distribute the application. Click on it and go to the Keys tab.

Select ADD KEY and click on the JSON type. This will allow us to download the JSON file containing the pass.

We can confirm that we have configured everything by going back to the Google Play Console and and reload the web page, you should seeing that the API access section now recognises the service something similar to this.

All the content of JSON downloaded file must be inside a secret on GitHub. In my case is called ANDROID_PLAYSTORE_ACCOUNT_KEY. Now we can focus on creating a GitHub Action workflow that contents the job that generates the release when a tag is made. 

In my case I have created a file called continuous_delivery.yaml . 

We have used ** to indicate that any type of tag will trigger this workflow. You may think that we can also put the branch as we have done in other deliveries but it won't work because not all the conditions must be met and then it will be triggered when you push on that branch or when a commit is made.

We created a job with an ubuntu machine. Then we create steps to create the .env and key.properties files, and other steps that we have used in other guides. For the creation of the publication to Google Play we will use the actions r0adkll/upload-google-play where we can read in the official documentation the parameters that may interest us.

We can see that we have needed to create 3 steps. With Start Android Release Build where we create the build and the next one (Upload Release Build to Artifacts) where we upload the artifact. Finally the Release Build to internal track step takes the file and publishes it to Google Play. 

Conclusions

We can see that when a tag is added to the master branch, the workflow published by the application is triggered, as shown in the image.