Version and automate your Play Store listings with Gradle Play Publisher v2.0
Published Oct 09, 2018 • Last updated Jun 17, 2020 • 7 min read
Have you ever wanted to keep track of changes going into your Play Store listings? Are you on a big team where managing “who has access to what” is a nightmare? Or, are you perhaps managing dozens of White Label distributions?
Excited yet? No? How about being able to continuously build and deploy your app every time you push to GitHub? If CI doesn’t get you excited, then I don’t what will! 🤓
If you’ve used v1.x versions of the plugin before and thought there was room for improvement, you’re not alone. Gradle Play Publisher v2.0 (GPP) covers all of the aforementioned cases and beyond. v2.0 adds more new features than I have fingers — and that’s not even including minor improvements or bug fixes!
Without further ado, let’s begin!
If you come from the v1.0 world, a lot has changed—hopefully all for the better! Be sure to read the migration guide.
If this is your first time publishing an app, you should probably start playing with the web console first since the initial app upload must be performed through the Play Console anyway. Otherwise, you should be able to breeze through the setup.
Setting up a Service Account
Ironically, I find the Microsoft App Center docs to be waaay better than Google’s own haphazard mess. Some notes:
- Don’t give the Service Account any roles when asked. This is recommended so the impact will be minimal if your keys get lost or stolen. Especially don’t give the Service Account the Owner role — that’s just ridiculous and I’m not sure why Microsoft wants that kind of access.
- I name my Service Account
CIand use the same credentials for all of my CI tasks so I have a single kill switch if something goes wrong.
- When granting the service account access to the Play Console, GPP only needs access to publish to alpha and beta channels at a bare minimum. However, you’ll most likely also want to let GPP manage your listings. As for the production channel, I don’t let my Service Account touch it since that’s a sensitive place to be. Again, it’s all about minimizing the impact of a lost or stolen Service Account since you’ll most likely be committing it to source control in some form or another.
Applying the plugin
Check out the README for the most up-to-date instructions.
Bootstrapping your project
You most likely already have listing details like an app title and description, promo graphics, release notes, etc. Wouldn’t it be nice if this could automatically be downloaded for you? Well… surprise! GPP does this for you. It’s as simple as running the bootstrap task:
Getting full resolution images
Edit: this is no longer necessary as of beta 2.
Sadly, there’s a caveat to the
bootstrap task: the Android Publisher API only returns image previews — not all that helpful if you’re trying to turn around and republish them:
So, how do we get around this? There are two solutions:
- 😃 You saved your screenshots somewhere and can just replace the downloaded previews with the real ones.
- 😡 You have to manually extract each screenshot from the Play Console.
#2 is somewhat unpleasant, so brace yourself:
- Find your app’s listing under
- Scroll down to
- For each screenshot, right click it and select
- Right above the
div, there will be an
imgtag with a link to the scaled-down version which looks like this: https://lh3.googleusercontent.com/…=h150-rw
- Replace the param value (
h15000so you get the highest resolution as a PNG. The link should now look like this: https://lh3.googleusercontent.com/…=h15000
- Rinse and repeat 🔄
This process is painful. I know. I’m sorry. Maybe now that will motivate you to try and get the Google Play team’s attention?
Using Gradle Play Publisher
As mentioned earlier, GPP includes a plethora of features. In fact, the plugin is almost feature complete in the sense that we cover every important Android Publisher API.
While GPP’s comprehensive README explains the how, it isn’t intended to provide the why. That’s where this article comes in. Below, you’ll find various use cases to improve your productivity.
Since GPP is a Gradle plugin, you can publish your app artifacts and listing from the command line. While that may not be too exciting, it can be a huge productivity boost if you need to upload APK splits or update your app’s translations all at once.
Versioning your metadata
I doubt I need to tell you why versioning is important, however, here’s a reminder if that’s not the case.
Publishing from a CI environment
One of the cooler use cases for GPP is publishing app updates on every build. You’ll first need to encrypt your credentials, but with that done, simply run your Gradle tasks as you normally would. I extract my secrets straight from Gradle.
Automatically incrementing the version code on every build
This is GPP’s coolest feature! Not only can you publish your app from CI, but you also won’t have to ever touch version codes again. Just push code and voila, a new version of your app is published with the lowest version code available.
As a bonus, you can easily revert a change simply by triggering a rebuild on an older commit!
Publishing to both the
alpha tracks at once (kinda)
If you haven’t been using the
internal track, you’re doing yourself a disservice — it’s insanely fast! The problem is that it’s meant to be, well… internal. What if you could publish your app to both the
internal track and then immediately to the
alpha track so your team gets the fastest updates while the outside world also gets your freshly baked builds?
You can do this with GPP by promoting a release. On CI, you would run
./gradlew publishBundle && ./gradlew promoteArtifact --track alpha. That’s it!
Generating release notes on the fly
How many times have you wished you could provide a better experience to your beta testers? (Hopefully it’s pretty often 😀.) With GPP, you can generate release notes from your commit messages to let your testers know what you’re up to.
Generating screenshots on the fly
This is a hypothetical since I haven’t done it yet, but if you had a process to automatically generate screenshots, you could pipe those to the
play folder and automatically publish your newly minted screenshots with the rest of your app on every build.
Automate all the things!
If you’ve thought of a use case I haven’t mentioned, please share it with me! I’d love to hear what people are building with GPP. And, if there’s something you don’t think is possible yet, feel free to file an issue.
How does it work?
Since the best way to figure out how something works is to poke at the source code yourself, I won’t go into too many details.
If you’re looking to contribute, here are the basics you’ll need to know:
PlayPublisherPluginis where everything starts. You’ll find task definitions,
PlayAccountConfigExtensionsetup, and a few other lifecycle tidbits.
- Most tasks extend
PlayPublishTaskBasewhich helps access the publishing API.
- You’ll need an instance of
AndroidPublisher.Editsand an edit ID (provided by
PlayPublishTaskBase) to use the API.
Note: if you’re thinking of creating a new task, definitely file an issue first so we can work with you to fit all the pieces I haven’t mentioned yet together.
Meet the team 👋
Björn Hurling and Christian Becker both incubated the project while Charles Anderson and I coincidentally both joined the project in the same week to kickstart the v2.0 spree. Björn is currently the Merge Master and Publishing Wizard.
All of us are happy to help and get feedback, so don’t hesitate to ping us on the interwebs.
That’s a wrap! I hope you enjoyed this look into what GPP v2.0 has to offer. While we think we have 99% of use cases covered, please file an issue if there’s anything you think could be improved — we’ll use this feedback to decide what to work on next. And of course, don’t hesitate to file bugs.