Automate your Android CI/CD Pipeline with GitHub Actions

When I came to play around with GitHub Actions CI/CD pipeline framework recently, I could not believe how simple and effective that functionality is!

It does not really matter, if you just want to automatically check each of your Git commits by using lint or to fully build your artefacts, GitHub actions allows you to do that with a simple YAML configuration.

GitHub actions allows the definition of different jobs that are automatically triggered on events happening within your Git repository (such as commits, pull, creation of a tag or releases, comments, creation of issues, and many more). As those job definitions are living in the same Git repository, its the perfect solution for managing your CI/CD pipeline as code within a self-contained GitHub repository.

Within this post, I will describe how I came to fully automate the CI/CD pipeline of my production Android App (TabShop) by using GitHub Actions.

GitHub action tab within my Android app repository

Kudos to Niraj Prajapati who wrote such a great blog post and who inspired me to fully automate my own Android app’s CI/CD pipeline.

Why – Whats the value for app publishers?

I can’t emphasise the value of a fully automated CI/CD pipeline enough! I spent hours over hours on manually building and testing my Android app, to finally sign it and push it to the Google Play Store. So far, I released 182 versions over 6 years. The build, test and release process gets more and more complex and error-prone. Freelance app publishers, like me, invest a significant amount of time into manual CI/CD processes that are much better spent in building innovations into the app itself.

That said, GitHub Actions does allow me to create and run a feature rich CI/CD release process fully automatically in the cloud, which helps me to save time and effort and to innovate!

Scope of my Android CI/CD Pipeline

This blog shows step-by-step how to implement the following tasks into your own GitHub Actions CI/CD pipeline:

  1. Build your app using the Gradle Build Tool
  2. Run your unit-tests
  3. Build a release app bundle
  4. Sign the app bundle
  5. Upload and expose the app bundle
  6. Push and release the app bundle in Google Play Console

Step 1: Automate your Android app build

The first step within our Android app’s CI/CD pipeline is to create a GitHub Action YAML file and to add a trigger that defines when the job should be run.

Navigate to your GitHub project repository and click on the ‘Actions’ tab where you find a button to create a new ‘workflow’.

GitHub offers a lot of standard build workflows for the most popular technology stacks. In our case we either choose to skip the template selection or we choose the Android CI workflow as shown below:

Choose the Android Gradle CI workflow

The resulting workflow will create an Android build job that already fulfills our first goal, which is to startup a Ubuntu instance, checkout your apps sourcecode and to execute the Gradle build file, as it is shown below:

Simple Android Gradle Build Job

The workflow above is triggered every time a ‘push’ or a ‘pull_request’ is triggered within your repository.

Step 2: Execute your unit-tests

A good unit tests coverage is recommended to safeguard your app against failing or buggy code contributions. In most Android app projects, the unit test code is part of your Git repository, so Gradle is also used to build and execute your tests by adding following step to your workflow:

Gradle step that runs your unit tests

Step 3: Build a release app bundle

Within the next step we will trigger the build of a release app bundle (AAB) that we will sign in the next step. App release bundles are the preferred way of shipping apps through the Google Play Appstore, as they are optimised in size and stripped of unnecessary content.

See below the workflow step that automatically builds our application release bundle:

Step 4: Sign the app bundle

Application bundles are typically signed with the certificate of a trustworthy app publisher, so that users can trust the origin of the installed app and that no third-party injected malicious parts into your app.

App marketplaces such as Google Play require apps to be signed with the certificate of the publisher to ensure the integrity of all published apps.

Therefore we will automatically sign our app bundle once its built by adding the below workflow step:

Sign an Android app bundle by using a GitHub action

The signing step above does need some additional information about your own certificate as well as the key store password and alias, which we will provide as safe GitHub secret placeholders as shown below:

  • secrets.SIGNING_KEY
  • secrets.ALIAS
  • secrets.KEY_STORE_PASSWORD
  • secrets.KEY_PASSWORD

Convert your certificate file into a base64 encoded string that can be used as a GitHub repository secret within the placeholder ‘secrets.SIGNING_KEY’. In case you are using a Mac you are lucky as the command for converting your secret file into a base64 encoded string is already provided by openssl, as it is shown below:

openssl base64 -in my-release-key.keystore -out my-release-key.keystore.base64

See the resulting list of GitHub secrets within the screenshot below:

GitHub Secrets used by the signing workflow step

Find the signin GitHub action that we used in our workflow below:

Step 5: Upload and expose the app bundle

Each workflow run does spin up a completely clean Ubuntu instance that is wiped after its finished.

If you would like to keep a build artefact for later download you have to define a build step to upload and persist the artefact, as it is shown below:

After your workflow is successfully finished you will find your file within the workflow execution screen:

Download Build Artefact

Step 6: Push and release the app bundle in Google Play Console

Now that we successfully built and signed our application, we would like to automatically push the app as a new beta release into your Google Play Console.

Again there is a dedicated GitHub Action that helps to achieve this cumbersome task, see below:

Another important prerequisite for a successful Google Play upload is the creation of a ‘Service account’ that holds the necessary IAM role for uploading artefacts into your Google Play account.

To create a new service account you have to navigate to your Google Play Console > Settings > API Access as it is shown in the screenshot below:

Google Play Console Service Account Creation

Create a new Service Account with release access right for your application. In case you are a Google Cloud user as well, you have to create the Service Account user within Google Cloud Console instead and then grant access to the selected app project.

Once you have your service account created, you have to create a JSON key for that service account and put it in a GitHub secret placeholder again. Just copy the JSON string into a GitHub secret field with the name ‘SERVICE_ACCOUNT_JSON’.

Create and download a JSON key for your Google Service Account

Once you have stored your service account key in a GitHub secret, you can create a workflow step to download it during the workflow run and store it in a file (service_account.json), as it is shown below:

Download the key to a local json file

The final step is to use the Upload Action to publish your application bundle to Google Play Console as it is shown below:

Upload and push an Android application bundle to Google Play

Important note here is that you will receive an error message if you did not enable the App Signing in your Google Play account. To opt-into app signing, you simply navigate to Google Play Console > Your App > Setting > App Signing, as shown below. You have to upload your signing key as private key file (which can be exported by Android Studio).

Summary

It’s amazing how easy and productive it is to use a GitHub Actions workflow to completely automate your Android app release process. It helps you to ensure consistent release quality and safes a lot of time especially for small and independent app publishers. See the running CI/CD workflow below.

Well done GitHub and Microsoft!

LeanInvestments Summer Challenge

Lean Investments

If you have a great idea for a web or mobile app and you and your team is able to implement this idea and you come from a European university, then maybe you’ll want to enter the Lean Investments Summer 2012 App Challenge.

In the contest, you build an application or service – for iPhone, the web or Android (by yourself or with a team we connect you with). The winner gets £10,000 (€12,500) of investment, three months of office space, six mentoring sessions with our founder, and introductions to three seed and venture-capital investors.

This isn’t a business-plan or pitch competition, where the winner is the person with the best slides or the most persuasive presentation. It’s about building something – a simple and quick prototype – that actually works and is useful. Real users are a bonus, but not required.

If you plan to return to full-time education after the summer, don’t worry – you can still enter. If you win, you can work on your killer app part-time while we assemble a team of people to help you take it forward.

The final deadline for app submission is at the end of the summer, but to enter you will have to have registered by 15 July 2012.

Lean Investments LP is a seed fund which invests in early-stage Internet and other technology startups based in Europe. The fund is the private vehicle of Tim Jackson, a leading figure in the European technology scene as a venture capitalist, entrepreneur, angel investor, commentator and technology journalist.

Finally AdMob and AdWords come together

Google announced that AdWords advertisers will be able to run campaigns in the AdMob network, a development that was expected since Google acquired AdMob for $750 million two years ago. In the last two years there was a big gap between AdWords, which offered traditional Web based adverts and AdMob which offered mobile ads on smartphone applications. Since more and more HTML5 based cross platform apps appear on the market, it was necessary to offer mobile ads also for these apps.

I also experienced that the value of AdWords ad clicks decreased dramatically, while the mobile ads boomed and brought more money per click, but that was just my impression.

Now both, mobile ads and Web based ads are coming together again and i am sure within the next years the revenu of mobile ads will also drop a lot.

Microsoft publishes on{X} Android App

A little surprise was Microsoft’s publication of a new Android App on{X} (yes its no typo, Microsoft published an Android exclusive App) App for automating context-sensitive tasks with the use of simple user defined scripts (called recipes). on{X} (pronounced like ‘on-ex’) lets you control and extend the capabilities of your Android phone using a JavaScript API to remotely program it. These recipes are much the same approach i published within my PhD thesis, except the fact that in my work they were called rules (ECA = Event Condition Action Rules). Its good to see that finally this idea of letting users customize their smart devices to react context-aware on user defined situations, got general acceptance by big players like Microsoft.

In order to push user defined rules to your Android phone you just have to install the on{X} application on your Android phone, log in to the website and app, and push rules to your phone. Rules you create using the on{X} website are immediately sent to your phone using the on{X} application. The rules you create run on your phone, using the phone’s abilities such as GPS, text messages, phone calls, and more. The phone’s abilities are exposed in the on{X} API as Triggers and Actions (as i already mentioned before within the global community this concept was published as Event, Condition Action rules).

on{X} can be used to set specific triggers based on the phone’s sensors and abilities, which typically define the context in which the user and his/her phone are in the moment. A wide variety of triggers are described in our documentation. Some basic triggers are location, weather, time, news, battery and wifi (what about activity, acceleration, movement, sound, light, direction, photo, companions and friends, …?)

Finally, i have to admit that on{X} is a nice tool for every user of a smartphone and that Microsoft published a work that very much goes along with my own implementations in my PhD work (which was published in 2004).

If you would like to try on{X} for yourself, scan the QR code and go on testing…

download the app

scan the QR code or enter
http://aka.ms/onxapp on your Android phone.

source: www.onx.ms

Search for open source code snipplets: koders

source: www.koders.com

koders.com is a really useful open source code search engine, which is able to find code snipplets within all the major open source code repositories on the Web. So if you are searching for e.g. Fibonacci, you are getting a list of code snipplets that are related to this word. You can aditionally filter for programming languages and available licences, which is quite helpful. The database that underlies Koders contains 3.3 billion lines of code and reflects the contents of the majority of world’s major open source repositories, with syntax-highlighting for over 30 programming languages. The search database is further enhanced with additional code and metadata from the Black Duck KnowledgeBase, the industry’s most complete database of open source and third-party code.

Estimate the cost for your coding projects

You need a new customized software solutions and want to know the implementation effort?

ReqPOOL Pocket Estimator offers a nice online and mobile tool for estimating the overall effort for the coding of your planned software project. You just have to fill in some stats of your planned software product and the tool calculates an estimated effort in person or programming hours.

Even if you think you know the effort for your coding project much better, this tool could give you another hint to replan 😉

CodeNow! Build, share & discover source code online

Today i read about a new startup company, called CodeNow, which offers an online platform for coding and compiling for different platforms.

As i expected it long time ago, the Web is also the future platform for coding, compiling and running source code! In my job i have to code for many different platforms and it got even worse with the increase of different mobile platforms, such as Android, Windows Phone 7, iOS, Symbian, Windows CE, Windows Mobile, …

So i already thought about, why not setting up a central Web platform/server for automatically compiling for all these platforms. As i am a heavy user of Google Docs, i also thought about the possibilities and advantages of using a shared online editor for coding source code with a distributed team of programmers. A central coding server could also include state-of-the-art continuous integration tools, such as build and release management, source code management, unit test management and deployment management for the different marketplaces.

A central platform could also provide a collection of connected virtual machines or real devices (iPhones, different Android devices, …) for integration testing on real devices, as this is quite a problem for freelance programmers who cannot afford to buy a large collection of test devices. I also read about programmers from Africa who are programming and publishing iPhone apps from internet cafes by using a very simple online iPhone simulator.

So for me the Web is the future development machine to code and compile for different platforms without the need to setup different compilers, enviroments and deployment environments.

screenshot taken from CodeNow webpage