Gradle Play Publisher: release automation for Android apps, in maintenance mode

What problem GPP solves for Android release engineers

Uploading an Android release by hand is a sequence of console clicks: build the artifact, sign it, open the Play Console, pick the track, upload, write the release notes, promote when the rollout is done. GPP moves that sequence into Gradle. The README describes the plugin as "Android's unofficial release automation Gradle Plugin" that can go from "building, uploading, and then promoting your App Bundle or APK to publishing app listings and other metadata." The audience is teams that already build with Gradle and want the Play Store side of a release to be reproducible and reviewable in version control. If your releases are one-off or you publish a handful of times a year, the setup cost described below is probably larger than the problem.

How GPP talks to Google Play: service account, API, Gradle tasks

The mechanism is a Google Cloud service account with access to the AndroidPublisher API. You create a GCP project, enable the API, generate a JSON key, and hand that key to the plugin. The service account is then invited as a user in the Play Console, where you scope it to specific apps and roles. The README's example grants full access to testing tracks and app listings while leaving production releases out, which is a sensible starting scope. From there, GPP exposes Gradle tasks: the README names bootstrapListing for validating the connection, plus tasks for publishing App Bundles, publishing APKs, uploading internal sharing artifacts, promoting artifacts, and publishing listings, in-app products and subscriptions. The repository is split into common/, play/ and a testapp/ module, with buildSrc/ holding build logic, which matches the shape of a multi-module Gradle plugin rather than a standalone CLI. Two constraints follow from this design. The first APK or App Bundle must be uploaded through the Play Console, because the README states that registering the app with the Play Store cannot be done through the Play Developer API. And uploads only work if the artifact is signed with your developer key, so a valid signingConfig is a hard prerequisite, not an optional step.

Installing GPP and running your first task

The plugin is applied per module, on each com.android.application module where you want it active, through the plugins {} DSL. The README shows version 4.1.1, which matches the most recent release listed. Kotlin build scripts use this form:

plugins {
    id("com.android.application")
    id("com.github.triplet.play") version "4.1.1"
}

Groovy build scripts use the same id with single quotes and the same version:

plugins {
    id 'com.android.application'
    id 'com.github.triplet.play' version '4.1.1'
}

Once the plugin is applied, authenticate it by pointing GPP at the JSON credentials you downloaded when creating the service account, then validate the connection by running the bootstrap task. The README recommends exactly this and says to remove the Project Owner role you gave the service account only after it succeeds:

./gradlew bootstrapListing

If you need unreleased code, the README documents snapshot builds from Sonatype's snapshots repository, published under the coordinates com.github.triplet.gradle:play-publisher:5.0.0-SNAPSHOT, added through buildscript repositories and dependencies:

buildscript {
    repositories {
        // ...
        maven("https://oss.sonatype.org/content/repositories/snapshots")
    }

    dependencies {
        // ...
        classpath("com.github.triplet.gradle:play-publisher:5.0.0-SNAPSHOT")
    }
}

Those are snapshots; the README's own framing is that you should be prepared to cut yourself on the bleeding edge.

Where GPP stops being the right tool

The first upload is the clearest boundary. GPP cannot register an app with the Play Store, so a brand new app still starts with a manual console upload before any of this works. The second boundary is maintenance. The README carries a section titled "Project status: maintenance mode" and states plainly that issues are ignored while pull requests are not, with the instruction to submit a PR if you need something done. That is an honest statement, but it changes what you are adopting: you are taking on a dependency whose bug fixes arrive when someone contributes them. Teams without Kotlin or Gradle plugin experience should weigh that carefully, because the fix may have to come from them. A third limitation is scope: GPP automates the Play Developer API surface it covers, and anything outside that surface, including the initial registration, stays manual. If your release process depends on console-side configuration that has no API equivalent, GPP will not remove that step.

GPP compared with a CI upload action

The related searches point at R0adkll/upload-google-play, a GitHub Action that does the upload step. The difference is where the logic lives. An action runs in a CI workflow file: you hand it an artifact path and credentials, and it pushes to Play as part of a job. GPP is a Gradle plugin inside your build, so the tasks are available on a developer machine as well as in CI, and metadata such as listings, in-app products and subscriptions can be authored as files in the repository and published by the same tool. That makes GPP a better fit when you want the whole release definition, artifact and metadata, under version control and runnable locally. The action is a better fit when your build is not Gradle-centric, or when you want the upload to be one step in a pipeline that already knows how to produce the artifact. Neither one removes the service account setup or the initial console upload.

Maintenance cost, licence and what to check before upgrading

The last push to the repository was on 2026-08-26, and the most recent release is 4.1.1 from 2026-08-11, with 4.1.0 the same day and 4.0.0 back in January 2026. The project is not archived, but the README's maintenance-mode statement is the operative fact: pull requests are the accepted path for changes, and issues are not triaged. Practically, that means pinning the plugin version in your build and reading the release notes before moving between major versions, because you cannot count on a maintainer to resolve a regression. GPP is licensed under MIT, which permits use, modification and redistribution provided the copyright notice and permission notice are included; that is a permissive licence, and it also means there is no warranty. None of this is legal advice, so check the LICENSE file in the repository and your own organisation's policy. The upgrade cost is mostly the Gradle plugin version line plus any Play API changes the release notes mention; the README does not document a rollback procedure, so keep the previous version pinned until a new one has run against a testing track.

Editorial conclusion

Adopt Gradle Play Publisher if your release steps are already Gradle tasks and you want Play uploads and listing metadata to live in the repository rather than in the Play Console UI. Do not adopt it if you need a maintainer to fix a blocking bug on your schedule: the project README states that issues are ignored and only pull requests are accepted, so any gap you hit becomes your own work. Before wiring it into a release pipeline, verify three things in your own setup: that the first APK or App Bundle is already uploaded through the Play Console, that your release builds have a valid signingConfig, and that the service account you created has the Play Console permissions for the tracks you intend to publish to. Run ./gradlew bootstrapListing first: it validates the GCP-to-Play connection before you trust the plugin with a real release.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Triple-T/gradle-play-publisher on GitHub