DEV Community: Sagar Viradiya

Modern Android app distribution with GitHub Actions Part - II

Sagar Viradiya — Wed, 18 Nov 2020 15:31:20 +0000

Photo by Bernd Dittrich on Unsplash

Hola folks 👋 , I'm back with part 2 of Modern Android app Distribution. In the first part, we saw how to automate the internal distribution using GitHub Actions and Internal App sharing. If you missed the first part you can check it 👇

Modern Android app distribution with GitHub Actions Part - I

Sagar Viradiya ・ Aug 25 '20

#android #github

In this part, we will see how to automate your production release through GitHub Actions and test track.

Automating app release through the test track

In the first part, we saw Internal app distribution which allows you to quickly share development builds. At BookMyShow we distribute our feature level builds for QA through Internal App Sharing. But what about a formal internal launch of the integrated build before you go live with the release? Test track allows you to distribute your build to a limited set of audience to test it out and get valuable feedback. Play console offers three tracks to distribute your build.

Internal (Limited to 100 testers)
Closed (Closed group which is invite-only)
Open (Anyone can join the testing program)

Once you are happy with your build you can promote it to closed, open, or production track depending on your current track. Read more about test tracks here.

Let's see how to automate this process. At a high level, we are looking at this.

Trigger for release build --> Build --> Distribute to one of the track

Let's build our workflow.

You need to decide on an event that will trigger your workflow. Since we are talking about pre-release distribution usually it is from the release branch and the event which will trigger the build has to be more specific. Tagging a release could be one of the events to trigger release build. Let's see how to achieve this.

name: Internal release
on:
  push:
    tags:
      - '[1-9]+.[0.9]+.[0.9]+'

As you can see you need to specify regex for your version name style and every time you tag your release it will trigger our workflow.

Note: Please make sure to bump the version name and version code before tagging your release.

Now we need to configure the build job.

jobs:
  build:
    name: Building release app
    runs-on: ubuntu-latest
    steps:
      - name: Checking out tag
        uses: actions/checkout@v2
      - name: Settting up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Runing build command
        # Run your own gradle command to generate release build.
        run: ./gradlew bundleRelease
      - name: Uploading build
        uses: actions/upload-artifact@v2
        with:
          name: bundle
          path: app/build/outputs/bundle/release/app-release.aab

This is very similar to the one we saw in the previous part.

Note: In case you are uploading apk you might need to upload mapping.txt as well which contains the obfuscated class, method, and field names mapped to the original names. This mapping file also contains information to map the line numbers back to the original source file line numbers. This file is required by Google Play to deobfuscate incoming stack traces from user-reported issues so you can review them in the Google Play Console.

The final job is to upload our build on the test track. Let's see how to achieve that.

First, we need to download our build that we uploaded in the previous job.

Note: In case you uploaded apk file in the previous job you need to upload a mapping file as well and the same you need to download.

upload_to_test_track:
    name: Uploading build to Internal test track
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Downloading build
        uses: actions/download-artifact@v2
        with:
          name: bundle

After downloading it is just a matter of using a GitHub Action for uploading build on the test track. You can use r0adkll/upload-google-play@v1 action.

      - name: Uploading to test track
        uses: r0adkll/upload-google-play@v1
        with:
          # Your service account JSON GitHub secret
          serviceAccountJsonPlainText: ${{ secrets.[your-github-service-acc-json-secret] }}
          # Your package name
          packageName: 'your-package-name'
          releaseFiles: app-release.aab
          track: internal

The key things that you need to specify are

Your service account JSON file as a plain text (Or as a JSON file) through GitHub secret.
Your application package name.
Track you want to upload build to(internal/production/alpha/beta).
Mapping file (In case you upload apk file)

The action also allows you to specify a bunch of other things but all of the above are important parameters that are mandatory.

Note: If you are uploading bundle you need to enroll in app signing by Google Play before uploading your app bundle on the Play Console. Read more about it here.

Congratulations! Your workflow for automating internal as well as production release is ready 💪

Here is gist of the full workflow 👇

This brings to an end of the two-part series on Modern Android app Distribution with GitHub Actions. Hope you guys had fun learning automating your build and distribution process. As always feedbacks are welcome so please comment or reach out to me on twitter.

That's it for now folks. Until next time 👋. Happy coding :)

Thanks to Akshansh and Nicola Corti for proofreading this.

Modern Android app distribution with GitHub Actions Part - I

Sagar Viradiya — Tue, 25 Aug 2020 15:09:50 +0000

Photo by Bernd Dittrich on Unsplash

Hey folks 👋 , First thing first, I hope everyone is safe and sound. With that out of way, let me ask you a couple of questions about your build/distribution cycle :

Do you manually create a build for your testing?
Are you still distributing your app over email/G-drive?
Want to automate the process of building and distributing?

If you answered yes to any of those questions, you need to stop what you're doing right now and automate your build/distribution cycle.

This is a 2 part series on Modern Android Distribution with GitHub Actions. I am going to help you automate your app distribution through GitHub Actions. So let's get started.

This blog assumes that you are well versed with GitHub Actions. If not then I highly recommend exploring it and come back.

In this part, we will be looking at how to automate internal app distribution through Internal App Sharing.

Automating internal app distribution through Internal App Sharing

Internal App Sharing is an excellent tool on Play console which allows you to share aab/apk internally with your QA and other stakeholders. At BookMyShow we are using it for sharing feature builds and integrated builds with QA. The whole experience is as good as installing an app from the play store except it is restricted to whitelisted emails. No more sideloading needed, and if that wasn't good enough, you could even integrate it into your workflow to share it on Slack once you upload apk/aab to Internal App Sharing(IAS).

At a high level, we are looking at this

Build --> Upload aab/apk to IAS --> Share link from the previous step on Slack.

Let's build our workflow.

You need to decide on an event that will trigger your workflow. It could be a push event to a specific branch or some other event. In most of the cases, it is a push event to a branch from where you are sharing internal build to QA. Let's configure that first.

name: Build, Upload to IAS and share on slack.
on:
  push:
    branches:
      # Specify branch from where you are sharing build
      - [branch_name]

Now let's see how to configure the build step we discussed earlier.

jobs:
  build:
    name: Building app
    runs-on: ubuntu-latest
    steps:
      - name: Checking out branch
        uses: actions/checkout@v2
          with:
            # Specify branch from where you are sharing build        
            ref: '[branch_name]'
      - name: Settting up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Runing build command
        # Run your own gradle command to generate build.
        run: ./gradlew bundleRelease
      - name: Uploading build
        uses: actions/upload-artifact@v2
        with:
          name: bundle
          path: app/build/outputs/bundle/release/app-release.aab

As you can see, build job has four tasks. This job, as we have specified, runs on an instance of a Linux machine. Just like how you would checkout branch on your new machine when you setup any project the same way here too you need to checkout branch from where you would like to create a build. The first step does that using a custom action actions/checkout@v2. Next, we need to setup JDK so that we can compile our project. The second step does that using a custom action actions/setup-java@v1.

Now our virtual Linux instance is ready with all setups; it's time to execute Gradle command to create a bundle(You can build apk too if you are not using bundle). The next step does that and creates a bundle file. Finally, the last step uploads our generated bundle so that we access it later in our next job - notice we have given name to our artifact called 'bundle' so that we can refer it later. Also, we have mentioned the file path to our bundle to be uploaded. If you want to share a file across jobs this is how you can achieve it. It uses custom action actions/upload-artifact@v2.

Alright so we are halfway through our workflow and so far we have managed to build and store our bundle on artifact so that we can use it in our next job.

Let's move on to our next job but before that…

I promise KitKat hasn't paid me for this 🤞

Ready? Let's move on then!

Since the last job is quite complex we will break it down stepwise.

Each job runs on a different instance of a Linux machine. Just how we configured our previous job, this job too runs on an instance of Linux.

Notice special 'needs' tag at line number 3 below. That tells GitHub that this job has a dependency on the name specified. In our case, it is build job.

Our final job has 3 steps. First, we download the build that we stored in the last step of the previous job. We are referring to an artifact that we want to download through the name that we have given 'bundle'.

upload_to_internal_app_sharing:
    name: Uploading build to IAS
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Downloading build
        uses: actions/download-artifact@v2
        with:
          name: bundle

Once we have bundle it's time to upload it to Internal App Sharing. Also, it's time for a shameless plug 🙈

My fellow engineers at BookMyShow and me wrote a custom GitHub action which allows you to upload build to Internal App Sharing. Check out more about it 👇

sagar-viradiya / internal-app-sharing-action

GitHub Action to upload aab/apk to Internal App Sharing on Play console

Just like other custom actions that we have seen so far, we will be using this to upload our build to Internal App Sharing.

This action requires 3 things to upload your build to IAS.

Your service account JSON in text format(We recommend to set it in your GitHub secret)
Your application's package name.
And the path to your build.

For the first two of those, you need to replace with your service account JSON as GitHub secret. The last one would be simply a file name since downloaded artifact would be at the root level unless you specify a custom path. In case you specify custom path while downloading please make sure you use the same path here.

Action spits out 3 outputs

downloadUrl - The download URL generated for the uploaded artifact.
certificateFingerprint - The SHA256 fingerprint of the certificate used to sign the generated artifact.
sha256 - The SHA-256 hash of the artifact.

Here is the step for uploading to Internal App Sharing.

      - name: Uplaoding to IAS
        id: ias
        uses: sagar-viradiya/internal-app-sharing-action@v1.1.0
        with:
          # Your service account JSON GitHub secret
          serviceAccountJsonPlainText: ${{ secrets.[your-github-service-acc-json-secret] }}
          # Your package name 
          packageName: '[your-package-name]'
          aabFilePath: 'app-release.aab'

In our next and final step, we notify downloadUrl output from above step on slack. Again it is using custom action rtCamp/action-slack-notify@v2.1.0. You need to mention the following :

Your slack webhook.
Channel where you want to notify.
Message - In our case downloadUrl output from previous step.
Title (Default would be 'Message').
Slack user name (Default would be 'rtBot') - The name of the sender of the message. Does not need to be a "real" username.

      - name: Sharing on slack
        uses: rtCamp/action-slack-notify@v2.1.0
        env:
          # Your slack webhook GitHub secret
          SLACK_WEBHOOK: ${{ secrets.[your-slack-webhook] }}
          # Slack channel where you want to notify
          SLACK_CHANNEL: [your-channel]
          SLACK_USERNAME: "JARVIS"
          SLACK_TITLE: "Internal testing build"
          SLACK_MESSAGE: ${{ steps.ias.outputs.downloadUrl }}

Wola! Your workflow for automating build and distribution through Internal app sharing is ready!

Here is gist of the full workflow 👇

In the next one, we will be exploring how to automate your production release, so stay tuned!

See you in part 2 👋

Stay safe!

Thanks Adnan A M for proofreading this.