> User Documentation Home

User Handbook
Tutorials
Resources

The following plugin provides functionality available through Pipeline-compatible steps. Read more about how to integrate steps into your Pipeline in the Steps section of the Pipeline Syntax page.

For a list of other such plugins, see the Pipeline Steps Reference page.

Google Play Android Publisher Plugin

View this plugin on the Plugins site

androidApkUpload: Upload Android AAB/APKs to Google Play

  • additionalVersionCodes (optional)
    Specifies the version codes of app files from a previous release which should be included in the release to be created by this build step.

    For example, if you have a Wear OS app file already released, but in this build step you only need to upload new mobile app files, you can enter the version code of the Wear OS app file to retain it for this new release, rather than having to upload it again here.

    Similarly, if you're using Multiple APK Support, you may have a situation where you only need to release an update to a single APK, and so you can use this functionality to retain the other APKs for this new release by entering their version codes.

    If you don't need this functionality, you can leave this field blank. Note that multiple entries must be comma-separated. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • apkFilesPattern (optional)
    • Type: String
  • deobfuscationFilesPattern (optional)
    Specifies filenames or patterns matching one or more ProGuard mapping files that should be uploaded to Google Play, so that it can automatically deobfuscate stacktraces from crash reports.

    Note that if you build an Android App Bundle (AAB file) with ProGuard enabled, the mapping file should already be embedded in the app bundle (typically as BUNDLE-METADATA/com.android.tools.build.obfuscation/proguard.map.
    In such cases, you shouldn't use this option since Google Play will reject any attempt to upload a mapping file when the app bundle has one embedded.

    You can use wildcards like "**/build/**/mapping.txt".
    See the 'includes' attribute of Ant's FileSet for the exact format.
    Note that multiple entries must be comma-separated.

    The base directory is the build's workspace. You can only upload mapping files that are located in your workspace.

    If there are multiple AAB/APK files being uploaded, and only one mapping file is found in the workspace, then that mapping file will be associated with each of the app files being uploaded. If there are multiple mapping files found, a basic attempt will be made to automatically associate each mapping file with its corresponding app file.
    Otherwise, if the number of mapping files found is not equal to the number of app files being uploaded, the build will fail, as this situation is not supported.

    For more information on deobfuscating crash stacktraces, see the Google Play documentation:
    https://support.google.com/googleplay/android-developer/answer/6295281 This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • expansionFilesPattern (optional)

    Specifies filenames or patterns matching zero or more expansion files that should be associated with the APK files being uploaded to Google Play.

    You can list as many or as few expansion files as you like — you have the option of associating previously-uploaded expansion files with the new APKs being uploading here.

    Naming

    Files must be named in the format [main|patch].<apk-version>.<application-id>.obb

    For example:
    • main.1000.com.example.mygame.obb
    • patch.1002.com.example.mygame.obb

    Patterns

    You can use wildcards like "**/build/**/*.obb".
    See the 'includes' attribute of Ant's FileSet for the exact format.
    Note that multiple entries must be comma-separated.

    The base directory is the build's workspace. You can only upload OBB files that are located in your workspace.

    Re-using existing expansion files

    If you don't provide a main or patch expansion file for every APK that you want to upload, enabling the "Re-use expansion files from existing APKs where necessary" option will automatically associate existing expansion file(s) with the APK(s) being uploaded.

    With this option enabled, if not enough expansion files are provided for all of the APK(s) being uploaded, this plugin will search for the newest, APKs on Google Play with main or patch expansion files — whether previously uploaded, or uploaded via the current build — and will associate those files with the new APK(s) being uploaded here.

    For example: If you want to upload a new APK, but the expansion files have not changed at all, you should leave the "Expansion files" field blank, but enable the checkbox.
    At build time, the latest existing main (and patch, if available) expansion files will be associated with the newly-uploaded APK.

    Similarly, if you have a new build, but only want to change the patch file, then just provide the patch expansion file and make sure this option is checked. The uploaded APK will have the existing main expansion file associated with it, along with the newly-uploaded patch file.

    Or, if you have a new main or patch expansion file, and want to apply that same file to multiple APKs being uploaded, name the expansion file according to the lowest versionCode that you're uploading. That expansion file will then be uploaded, and applied to the APKs with higher versionCodes that were uploaded in the same build. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • filesPattern (optional)
    Specifies filenames or patterns matching one or more AABs or APKs that should be uploaded to Google Play.

    You can use wildcards like "**/build/outputs/*/*-release.apk".
    See the 'includes' attribute of Ant's FileSet for the exact format.
    Note that multiple entries must be comma-separated.

    The base directory is the build's workspace. You can only upload AAB or APK files that are located in your workspace.

    Applications which have several files per release, taking advantage of Multiple APK Support, must have all of their APKs uploaded together, and all APKs must have the same application identifier (APK package name).

    If no value is provided, the default is **/build/outputs/**/*.aab, **/build/outputs/**/*.apk. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • googleCredentialsId (optional)
    Specifies which credential to use in order to connect to Google Play.

    The selected credential must be a "Google Service Account from private key" — if you have not added one already, refer to the documentation on this plugin's page.

    By choosing the "Parameter expression" option, you can also provide a credential at build time, either from an environment variable, or from a build parameter, e.g. the Credentials Parameter type.
    But you can use any type of expression, so long as it expands to the name of a "Google Service Account from private key" credential at build time. This field supports substituting environment variables in the form ${SOME_VARIABLE} at build time.
    Note that variables in the form $SOME_VARIABLE are not accepted by the Credentials Plugin.
    • Type: String
  • inAppUpdatePriority (optional)
    Specifies the priority of this app release for the in-app update feature of the Google Play Core Library.

    If you don't use this feature, or don't need to set a priority, you can leave this field blank; it will default to 0. Otherwise the value must be a whole number between 0 (lowest priority) and 5 (highest priority).

    For more information on using in-app updates, see the documentation:
    https://developer.android.com/guide/playcore/in-app-updates This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • nativeDebugSymbolFilesPattern (optional)
    Specifies filenames or patterns matching one or more zip files containing native library symbols that should be uploaded to Google Play, so that it can automatically deobfuscate native crash dumps.

    Note that if you build an Android App Bundle (AAB file) with native libraries, using Android Gradle Plugin version 4.1 or newer, you can choose to automatically embed the native symbols into the app bundle file.
    Therefore you don't need to use this option to upload the symbols separately. But if you do, the contents of this symbols file will supersede those embedded in the bundle.

    You can use wildcards like "**/build/**/native-debug-symbols.zip".
    See the 'includes' attribute of Ant's FileSet for the exact format.
    Note that multiple entries must be comma-separated.

    The base directory is the build's workspace. You can only upload symbols files that are located in your workspace.

    If there are multiple AAB/APK files being uploaded, and only one symbols file is found in the workspace, then that symbols file will be associated with each of the app files being uploaded. If there are multiple symbols files found, a basic attempt will be made to automatically associate each symbols file with its corresponding app file.
    Otherwise, if the number of symbols files found is not equal to the number of app files being uploaded, the build will fail, as this situation is not supported.

    For more information on deobfuscating crash stacktraces, see the Google Play documentation:
    https://support.google.com/googleplay/android-developer/answer/6295281 This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • recentChangeList (optional)
    You can optionally apply "What's new" text to the uploaded file(s), in order to inform your user of changes contained in the new app version.

    You add entries for as many or as few of your supported language as you wish, but each language must already have been added to your app, under the "Store Listing" section in the Google Play Developer Console.

    The language must match the language code shown in the Developer Console, e.g. "en-GB" for British English, or "ar" for Arabic.

    The text may be between zero and 500 characters.

    For more information on describing what's new in your app, see the Google Play documentation:
    https://support.google.com/googleplay/android-developer/answer/189724 Both fields support substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
      Array / List of Nested Object
    • language
      • Type: String
    • text
      • Type: String
  • releaseName (optional)
    The release name, used to identify this release in the Google Play Console UI. Not required to be unique among releases. If no value is entered, Google Play will set the release name to the versionName of the app file being uploaded.

    Any instances of {versionCode} or {versionName} in the value will be replaced by the respective value from the app file being uploaded. If multiple files are uploaded, the one with the lowest versionCode will be used.

    For example, entering Version {versionName}-${GIT_COMMIT} as release name could yield a release name on Google Play something like Version 1.2.3-b2c3d3e4. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • rolloutPercent (optional)
    • Type: double
  • rolloutPercentage (optional)
    The percentage of users in the given track to which the uploaded file(s) should be rolled out.

    If you enter 100%, the app will be rolled out to all users, and the release will be considered complete, i.e. you will be unable to reduce the rollout percentage for this release.

    If you enter 0%, a draft release will be created, meaning that users will not yet see it; the existing file(s) released in the given track, if any, will remain in place.

    For more information on staged rollouts, see the Google Play documentation:
    https://support.google.com/googleplay/android-developer/answer/6346149 This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • trackName (optional)
    Specifies the release track to which the given app file(s) will be assigned, or uploaded.

    Regular release tracks

    You can enter the name of a custom track, or one of the built-in tracks:
    • internal
    • alpha
    • beta
    • production
    For these tracks, you have the choice of rolling out the uploaded app files to all existing users immediately, or doing a staged rollout so that only a percentage of your existing userbase will be able to download the new version. Alternatively, you can set the rollout percentage to zero to create a draft release.

    For more information on using the internal, alpha, beta or custom testing tracks, see the Google Play documentation:
    https://support.google.com/googleplay/android-developer/answer/3131213

    Internal App Sharing

    Alternatively, you can use the special track name internal-app-sharing, which will upload the app file — either an AAB or APK file — directly to Internal App Sharing. In this case, no other build step configuration is required, other than the Google Play credentials.

    Upon successful upload, the download URL for the uploaded file will be output to the build log. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • usePreviousExpansionFilesIfMissing (optional)
    • Type: boolean

androidApkMove: Move Android apps to a different release track

If you have already uploaded files to Google Play, whether manually, via the "Upload Android AAB/APK to Google Play" post-build action, or by other means, this build step allows you to change the release track for specific versions.

For example, you can use this to promote an app currently in alpha testing to the beta release track, once you've decided it's ready for a wider audience.

Similarly, once you're ready for release, you can move from beta to a staged rollout, or directly to production.

Note that "downgrading" release tracks, e.g. from production to alpha is not possible.
  • apkFilesPattern (optional)
    • Type: String
  • applicationId (optional)
    Application ID (i.e. APK package name) of the app being assigned to a new release track. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • filesPattern (optional)
    Specifies filenames or patterns matching one or more AAB or APK files from which the version codes should be read, in order to determine which app versions should be re-assigned to a new release track.

    Note that these files should have already been uploaded — this build step will not do any uploading; it will only move existing app versions from one release track to another. To upload app files, use the "Upload Android AAB/APK to Google Play" post-build action.

    You can use wildcards like "**/build/outputs/*/*-release.apk".
    See the 'includes' attribute of Ant's FileSet for the exact format.
    Note that multiple entries must be comma-separated.

    The base directory is the build's workspace. You can only reference AAB or APK files that are located in your workspace.

    If no value is provided, the default is **/build/outputs/**/*.aab, **/build/outputs/**/*.apk. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • fromVersionCode (optional)
    • Type: boolean
  • googleCredentialsId (optional)
    Specifies which credential to use in order to connect to Google Play.

    The selected credential must be a "Google Service Account from private key" — if you have not added one already, refer to the documentation on this plugin's page.

    By choosing the "Parameter expression" option, you can also provide a credential at build time, either from an environment variable, or from a build parameter, e.g. the Credentials Parameter type.
    But you can use any type of expression, so long as it expands to the name of a "Google Service Account from private key" credential at build time. This field supports substituting environment variables in the form ${SOME_VARIABLE} at build time.
    Note that variables in the form $SOME_VARIABLE are not accepted by the Credentials Plugin.
    • Type: String
  • inAppUpdatePriority (optional)
    Specifies the priority of this app release for the in-app update feature of the Google Play Core Library.

    If you don't use this feature, or don't need to set a priority, you can leave this field blank; it will default to 0. Otherwise the value must be a whole number between 0 (lowest priority) and 5 (highest priority).

    For more information on using in-app updates, see the documentation:
    https://developer.android.com/guide/playcore/in-app-updates This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • releaseName (optional)
    The release name, used to identify this release in the Google Play Console UI. Not required to be unique among releases. If no value is entered, Google Play will set the release name to the versionName of the app file being moved. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • rolloutPercent (optional)
    • Type: double
  • rolloutPercentage (optional)
    The percentage of users in the given track to which the uploaded file(s) should be rolled out.

    If you enter 100%, the app will be rolled out to all users, and the release will be considered complete, i.e. you will be unable to reduce the rollout percentage for this release.

    If you enter 0%, a draft release will be created, meaning that users will not yet see it; the existing file(s) released in the given track, if any, will remain in place.

    For more information on staged rollouts, see the Google Play documentation:
    https://support.google.com/googleplay/android-developer/answer/6346149 This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • trackName (optional)
    Specifies the release track to which the given app file(s) will be re-assigned.

    You can enter the name of a custom track, or one of the built-in tracks:
    • internal
    • alpha
    • beta
    • production
    For these tracks, you have the choice of rolling out the uploaded app files to all existing users immediately, or doing a staged rollout so that only a percentage of your existing userbase will be able to download the new version.

    For more information on using the internal, alpha, beta or custom testing tracks, see the Google Play documentation:
    https://support.google.com/googleplay/android-developer/answer/3131213 This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String
  • versionCodes (optional)
    This specifies which version codes should be assigned to a new release track.
    Note that multiple entries must be comma-separated. This field supports substituting environment variables in the form ${SOME_VARIABLE} or $SOME_VARIABLE at build time.
    • Type: String

Was this page helpful?

Please submit your feedback about this page through this quick form.

Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?

    


See existing feedback here.