Establishing a reliable continuous delivery and deployment process is often very important as it might greatly reduce the length of time needed for the validation and verification of the software product. This is also true for Android projects, especially the ones aimed at short time to market.
For me, one of the most crucial time savers is the gradle-play-publisher plugin, which allows me to publish the APKs as soon as the build is finished. However, you need the Google service account for that.
The Google service account is an account that might be used by your applications to access all the Google APIs, including the ones for Google Play publishing (Publishing API). This API allows for example to:
While granting this account the required permissions, you cannot choose which particular apps it can access - it’s either all or nothing. So if you have more than one application on your Google developer account, the service account will be able to reach them all.
Bearing this in mind, you should always protect the service account from abuse. The documentation also does warn you:
We recommend not giving third parties access to any service accounts you may create. We especially recommend not giving access to any private keys for your service account. Doing so provides anonymous access to your account that can be shared with anyone.
If you are going to use the Publishing API in your builds, you definitely should take the appropriate measures to keep the service account key secure. Depending on your company policies (e.g. repositories access), the size of your team, your customer needs and policies, you might consider:
So how you can not store the key at all? Well, I have lied a bit. You must store it somewhere, but this example will show you how to store it as a secret value on a build server instead of a repository. This way you don’t have to protect the repository itself, but the build server instead. Is it easier? It depends. But it’s just one of the methods you can choose.
Most of the automation servers like Jenkins or TeamCity have the ability to store a secret value, which you can use during the build. Whether it is really secure depends on the particular software you use, the build script (which may be printing the secret value to the build logs for example) and the access you give other people to the infrastructure and build configuration.
In this example, the secret value is stored on a TeamCity server and it will be available to the build in an environment variable.
There are plenty of ways you can read the environment variable during the build. This example uses a Gradle task to generate a file containing the key needed by the
gradle-play-publisher plugin before the publication.
The way it works is pretty straightforward:
prodRelease, which produce (among the others):
generateGooglePlayDeploymentJsonFiletask, which expects the Google service account key (in JSON format) in the environment variable and saves it to a specified file.
Of course this simple script might be further improved and I encourage you to do it on your own.
The Gradle tasks used for the publication in this example are:
publishApkProdRelease. Publishing the APKs with them is as simple as running these tasks like this:
And you can see in the logs that it works:
[10:59:52][Step 1/1] Configuring Google Play deployment JSON file for task: task ':app:generateDevReleasePlayResources' [10:59:52][Step 1/1] Configuring Google Play deployment JSON file for task: task ':app:generateProdReleasePlayResources' ... [11:00:50][Step 1/1] :app:assembleProdRelease [11:00:50][Step 1/1] :app:generateGooglePlayDeploymentJsonFile [11:00:50][Step 1/1] :app:generateProdReleasePlayResources [11:00:58][Step 1/1] :app:publishApkProdRelease
Now, having this process configured, you can safely delete the Google service account key file, so no one will ever abuse it (unless they somehow read it from the build server, which is your only worry now). In case your server dies and you lose the key, you can just invalidate it and generate another one in the Google APIs Console.
Protecting the service account key may be challenging, but it’s very important and worth considering. You should assess the options you have, their pros and cons, the risks and profits. Keep in mind that any level of protection is better than no protection at all.
This article is crossposted with author's personal blog.