agentsclimarketplace

Play store release

Skill almasumdev/awesome-mobile-release-agent-skills/.github/skills/stores/play-store-release

Release to Google Play using internal/closed/open tracks, AAB uploads, and the Data Safety form. Use this when shipping an Android build to the Play Console.From its SKILL.md

Install
npx -y skills add almasumdev/awesome-mobile-release-agent-skills --skill play-store-release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.3 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it

Play Store Release

Instructions

The Play Console has four public tracks: internal, closed, open, and production. A healthy release pipeline promotes the same AAB from internal → production without rebuilding.

1. Track Model

TrackAudienceMax testersReview
Internal testingUp to 100 testers by email100None (minutes)
Closed testingNamed tester lists or Google GroupsUnlimitedSame-day
Open testingAnyone with the opt-in linkUnlimited1–7 days
ProductionPublic1–7 days (often 24h)

Always upload to internal first. Promote the exact same AAB between tracks; never rebuild.

2. Build the AAB

# Flutter
flutter build appbundle --release \
  --build-name=1.4.2 --build-number=$GITHUB_RUN_NUMBER

# Native Gradle
./gradlew :app:bundleRelease \
  -PversionName=1.4.2 -PversionCode=$GITHUB_RUN_NUMBER

Output: app/build/outputs/bundle/release/app-release.aab.

3. Service Account for API Uploads

  1. Play Console → Setup → API access → Create new service account.
  2. Grant Release manager role for the app.
  3. Download the JSON key; store as PLAY_SERVICE_ACCOUNT_JSON CI secret.

4. Upload with fastlane supply

android/fastlane/Fastfile:

platform :android do
  desc "Upload AAB to the internal track"
  lane :internal do
    upload_to_play_store(
      track: "internal",
      aab: "../build/app/outputs/bundle/release/app-release.aab",
      json_key_data: ENV["PLAY_SERVICE_ACCOUNT_JSON"],
      release_status: "completed",
      skip_upload_metadata: false,
      skip_upload_images: true,
      skip_upload_screenshots: true,
    )
  end

  desc "Promote internal build to production at 5%"
  lane :promote do
    upload_to_play_store(
      track: "internal",
      track_promote_to: "production",
      rollout: "0.05",
      json_key_data: ENV["PLAY_SERVICE_ACCOUNT_JSON"],
      skip_upload_aab: true,
    )
  end
end

5. Release Notes

Write per-locale release notes under android/fastlane/metadata/android/<locale>/changelogs/<versionCode>.txt. supply picks them up automatically. Keep them ≤ 500 chars and user-facing.

6. Data Safety Form

Mandatory for every app. Declare:

  • Data collected (categories: location, personal info, financial info, etc.).
  • Purpose (analytics, fraud prevention, advertising).
  • Sharing with third parties.
  • Encryption in transit (true if you use HTTPS — you do).
  • Deletion request mechanism (URL or in-app flow).

Update the form before uploading an AAB that changes data flows. See the dedicated play-data-safety skill for details.

7. Staged Rollout

Never jump to 100% on day one. Start at 5%, promote on evidence:

# Increase rollout
bundle exec fastlane supply --track production --rollout 0.20 --skip_upload_aab true

# Halt rollout (rollback in §10)
bundle exec fastlane supply --track production --rollout 0 --skip_upload_aab true

8. Testing Tracks With Real Users

  • Open testing: create an opt-in URL, share in-app or via email to beta users.
  • Closed testing: add Google Groups ([email protected]) in Play Console → Testing → Closed testing.
  • Internal testing surface appears under Play Store → Menu → Manage apps → Beta.

9. In-App Updates

For fast pickup of critical updates, integrate Play In-App Updates:

val appUpdateManager = AppUpdateManagerFactory.create(context)
appUpdateManager.appUpdateInfo.addOnSuccessListener { info ->
    if (info.updateAvailability() == UpdateAvailability.UPDATE_AVAILABLE &&
        info.isUpdateTypeAllowed(AppUpdateType.IMMEDIATE)) {
        appUpdateManager.startUpdateFlowForResult(info, AppUpdateType.IMMEDIATE, activity, REQ_UPDATE)
    }
}

Use IMMEDIATE only for truly critical hotfixes; FLEXIBLE for everything else.

10. Halting / Rolling Back

  • Halt staged rollout: set rollout to 0 (above). Users on the old version stay; new installs pause receiving the new one.
  • Full rollback: re-promote the previous AAB from internal to production. You cannot decrement versionCode, so the "rollback" is really a new build of the previous source.

11. Review Pitfalls

  • Target API level: Google enforces a rolling minimum (currently API 34 for new and updated apps). Bump promptly each August.
  • Permissions justification: prominent disclosure screens are mandatory for sensitive permissions (location, SMS, call logs).
  • Ads SDKs: declare in the app content section; ads for minors have extra rules.
  • Background location: requires a separate review form.

12. Checklist

  • AAB built (not APK) with a unique, monotonically increasing versionCode.
  • Uploaded to internal track first; smoked tested on 2+ real devices.
  • Data Safety form current and matches actual SDK behaviour.
  • Release notes provided for every supported locale.
  • Production rollout starts at 5%, gated by the crash-free SLO.
  • Service account JSON scoped to this app, stored only in CI secrets.
  • Target API level meets Google's current requirement.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most ship operate skills give in ~1.3k tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymentin 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git tagin 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasein 14 of 779

Said here and by no other author read

  • upload to internal track first
  • promote the same AAB between tracks
  • use a unique monotonically increasing versionCode
  • grant the service account release manager role
  • store the service account JSON in CI secrets
  • use fastlane supply for uploads

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.