在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):Triple-T/gradle-play-publisher开源软件地址(OpenSource Url):https://github.com/Triple-T/gradle-play-publisher开源编程语言(OpenSource Language):Kotlin 99.9%开源软件介绍(OpenSource Introduction):Gradle Play PublisherGradle Play Publisher (GPP) is Android's unofficial release automation Gradle Plugin. It can do anything from building, uploading, and then promoting your App Bundle or APK to publishing app listings and other metadata. Table of contents
Quickstart guide
PrerequisitesInitial Play Store uploadThe first APK or App Bundle needs to be uploaded via the Google Play Console because registering the app with the Play Store cannot be done using the Play Developer API. For all subsequent uploads and changes, GPP may be used. Signing configurationTo successfully upload apps to the Play Store, they must be signed with your developer key. Make sure you have a valid signing configuration. Service AccountTo use GPP, you must create a service account with access to the Play Developer API:
Basic setupInstallationApply the plugin to each individual Kotlinplugins {
id("com.android.application")
id("com.github.triplet.play") version "3.7.0"
} Groovyplugins {
id 'com.android.application'
id 'com.github.triplet.play' version '3.7.0'
} Snapshot buildsIf you're prepared to cut yourself on the bleeding edge of GPP development, snapshot builds are
available from
Sonatype's Kotlinbuildscript {
repositories {
// ...
maven("https://oss.sonatype.org/content/repositories/snapshots")
}
dependencies {
// ...
classpath("com.github.triplet.gradle:play-publisher:4.0.0-SNAPSHOT")
}
} Groovybuildscript {
repositories {
// ...
maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
}
dependencies {
// ...
classpath 'com.github.triplet.gradle:play-publisher:4.0.0-SNAPSHOT'
}
} Authenticating Gradle Play PublisherAfter you've gone through the Service Account setup, you should have a JSON file
with your private key. Add a android { ... }
play {
serviceAccountCredentials.set(file("your-key.json"))
}
Task organizationGPP follows the Android Gradle Plugin's (AGP) naming convention: Lifecycle tasks to publish multiple product flavors at once are also available. For example,
To find available tasks, run Managing artifactsGPP supports uploading both the App Bundle and APK. Once uploaded, GPP also supports promoting those artifacts to different tracks. Common configurationSeveral options are available to customize how your artifacts are published:
Example configuration: import com.github.triplet.gradle.androidpublisher.ReleaseStatus
play {
// Overrides defaults
track.set("production")
userFraction.set(0.5)
updatePriority.set(2)
releaseStatus.set(ReleaseStatus.IN_PROGRESS)
// ...
} Uploading release notesWhile GPP can automatically build and find your artifact, you'll need to tell the plugin where to find your release notes. Add a file under As an example, let's assume you have these two different release notes:
When you publish to the beta channel, the
Uploading developer facing release namesThe Play Console supports customizing release names. These aren't visible to users, but may be
useful for internal processes. Similar to release notes, release names may be specified by placing
a
If it makes more sense to specify the release name in your build script, the play {
// ...
releaseName.set("My custom release name")
}
There is also a
Uploading a pre-existing artifactBy default, GPP will build your artifact from source. In advanced use cases, this might not be the desired behavior. For example, if you need to inject translations into your APK or App Bundle after building it but before publishing it. Or perhaps you simply already have an artifact you wish to publish. GPP supports this class of use cases by letting you specify a directory in which publishable artifacts may be found: play {
// ...
artifactDir.set(file("path/to/apk-or-app-bundle/dir"))
} For quick access, you can also use the ./gradlew publishBundle --artifact-dir path/to/app-bundle/dir
Uploading mapping files
By default, GPP will look for a file called
Retaining artifactsGPP supports keeping around old artifacts such as OBB files or WearOS APKs: play {
// ...
retain {
artifacts.set(listOf(123)) // Old APK version code
mainObb.set(123) // Old main OBB version code
patchObb.set(123) // Old patch OBB version code
}
} Publishing an App BundleRun Defaulting to the App BundleYou'll notice that if you run play {
// ...
defaultToAppBundles.set(true)
} Publishing APKsRun Uploading an Internal Sharing artifactRun Retrieving the download URLAfter running an Internal Sharing task, the output of the API response will be stored in the
following directory: For example, here are the contents
of {
"certificateFingerprint": "...",
"downloadUrl": "...",
"sha256": "..."
} Installing Internal Sharing artifactsTo accelerate development, GPP supports uploading and then immediately installing Internal Sharing
artifacts. This is similar to the AGP's Run Promoting artifactsExisting releases can be promoted and/or updated to the configured track
with By default, the track from which to promote a release is determined by the most unstable channel
that contains a release. Example: if the alpha channel has no releases, but the beta and prod
channels do, the beta channel will be picked. To configure this manually, use the play {
// ...
fromTrack.set("alpha")
} Similarly, the track to which to promote a release defaults to the play {
// ...
promoteTrack.set("beta")
} If you need to execute a one-time promotion, you can use the CLI args. For example, this is how you
would promote an artifact from the alpha ./gradlew promoteArtifact \
--from-track alpha --promote-track beta \
--release-status inProgress --user-fraction .25 If you only need to update the rollout percentage of an existing in-progress release, you can do so
with the ./gradlew promoteArtifact --update production --user-fraction .5 Finishing a rolloutIf you have an ongoing Handling version conflictsIf an artifact already exists with a version code greater than or equal to the one you're trying to upload, an error will be thrown when attempting to publish the new artifact. You have two options:
Example configuration: import com.github.triplet.gradle.androidpublisher.ResolutionStrategy
play {
// ...
resolutionStrategy.set(ResolutionStrategy.IGNORE)
} Post-processing outputs sanitized by auto resolutionFor example, you could update your app's version name based on the new version code: import com.github.triplet.gradle.androidpublisher.ResolutionStrategy
play {
// ...
resolutionStrategy.set(ResolutionStrategy.AUTO)
}
androidComponents {
onVariants { variant ->
for (output in variant.outputs) {
val processedVersionCode = output.versionCode.map { playVersionCode ->
// Do something to the version code...
// In this example, version names will look like `myCustomVersionName.123`
"myCustomVersionName.$playVersionCode"
}
output.versionName.set(processedVersionCode)
}
}
} Managing Play Store metadataGPP supports uploading any metadata you might want to change with each release, from screenshots and descriptions to in-app purchases and subscriptions. QuickstartGPP includes a bootstrap task that pulls down your existing listing and initializes everything for
you. To use it, run
Directory structureGPP follows the Android Gradle Plugin's source set
guidelines and priorities.
In addition to merging metadata across variants, GPP merges translations. That is, if a resources is
provided in a default language such as Publishing listingsRun Uploading global app metadataBase directory:
Uploading text based listingsBase directory:
Uploading graphic based listingsDirectory: Image files are organized a bit differently than in previous sections. Instead of the file name, the
parent directory's name is used as the media type. This is because multiple images may be provided
for the same media type. While file names are arbitrary, they will be uploaded in alphabetical order
and presented on the Play Store as such. Therefore, we recommend using a number as the file name
(
Publishing in-app productsRun Manually setting up in-app purchase files is not recommended. Bootstrap them instead
with Working with product flavorsWhen working with product flavors, granular configuration is key. GPP provides varying levels of
granularity to best support your needs, all through the Kotlinplay {
// In a simple app, this play block is all you'll need. However, in an app with product flavors,
// the play block becomes a place to store default configurations. Anything configured in here
// will apply to all product flavors, that is, unless an override is supplied in the playConfigs
// block.
}
android {
// Suppose we have the following flavors
flavorDimensions("customer", "type")
productFlavors {
register("firstCustomer") { setDimension("customer") }
register("secondCustomer") { setDimension("customer") }
register("demo") { setDimension("type") }
register("full") { setDimension("type") }
}
playConfigs {
// Now, we can configure GPP however precisely is required.
// Configuration overrides occur in a cascading manner from most to least specific. That is,
// a property configured in a build type + flavor combo overrides that same property
// configured in a flavor combo, which overrides a build type combo, which in turn overrides
// the play block. Properties not configured are inherited.
register("firstCustomerFullRelease") { ... } // Build type + flavor
register("firstCustomer") { ... } // Flavor
register("release") { ... } // Build type
}
} |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论