play-store-submission

name	play-store-submission
description	Google Play Store submission - Data Safety form, target API policy, App Bundles, signing by Google Play, testing tracks, and staged rollout. Use when preparing a first or recurring submission.

Play Store Submission

Instructions

Play Store review is usually faster than App Store, but its policies on target API, privacy, permissions, and content change continually. Plan submissions with the current rulebook in hand, not last year's.

1. Accounts, Signing, and Bundles

• Google Play developer account (one-time fee).
• Application signing by Google Play (recommended). You sign the upload with an upload key; Google re-signs with the app signing key. Keep the upload keystore in secure storage.
• Publish Android App Bundles (.aab). APKs as uploads are limited; AABs enable dynamic delivery and smaller installs.
• applicationId in Gradle matches the Play Console app record.

// app/build.gradle.kts
android {
    namespace = "com.example.app"
    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 34          // update yearly per Play policy
        versionCode = 1234
        versionName = "2.5.0"
    }
    bundle {
        language  { enableSplit = true }
        density   { enableSplit = true }
        abi       { enableSplit = true }
    }
}

2. Target API Level Policy

Play enforces a moving target API requirement. Every August, new apps must target the API that was released the previous year; existing apps follow shortly after. In 2026 this means targetSdk 34+.

• Update targetSdk annually and address breaking changes: permission changes, scoped storage, photo picker, foreground service types, background work restrictions.
• Failure to update results in removal from search for new users.

3. Data Safety Form

Play's equivalent of the privacy label.

• Declare every type of data collected and shared, per SDK and backend.
• State data retention and deletion policy.
• Declare whether each data type is encrypted in transit (TLS).
• Provide a way for users to request data deletion. As of 2024, account deletion must be available in-app or via a web URL; not buried.

Audit and update on every release that changes SDKs or collection.

4. Permissions and Policy

• Runtime permissions on Android 6+: request at the point of use, with rationale.
• Android 13+: POST_NOTIFICATIONS, granular media permissions (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO).
• Android 14+: foreground service types must be declared (dataSync, mediaPlayback, location, etc.) with matching permissions, or the service will crash.
• Sensitive permissions (SMS, Call Log, AccessibilityService) require a Play Console declaration and use-case justification.
• QUERY_ALL_PACKAGES requires declared justification.

<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES"/>
<application>
  <service android:name=".SyncService"
           android:foregroundServiceType="dataSync"/>
</application>

5. Store Listing

• App name (30 chars), short description (80 chars), full description (4000 chars).
• Icon 512x512 PNG.
• Feature graphic 1024x500.
• Phone screenshots (at least 2, up to 8). Tablet screenshots if declaring tablet support.
• Categorization, content rating via IARC questionnaire.
• Privacy policy URL required for all apps.
• Contact details for developer.

Localize every field for each declared locale. Google Play shows translations algorithmically but hand-crafted beats autotranslate.

6. Testing Tracks

• Internal testing: up to 100 testers, instant.
• Closed testing: by email list or Google Group, larger.
• Open testing: public opt-in link.
• Production: live to the world.

New personal developer accounts (post-2023) must run a closed test of at least 20 testers for 14 days before publishing to production.

Use the lower tracks for every build. Do not upload straight to production.

7. Signing and Integrity

• Enable Play Integrity API for anti-tamper and device integrity checks if your app handles payments or high-value logins.
• Rotate upload keys periodically; Google retains the app signing key.
• Protect the upload key with HSM or CI secret storage; loss of the upload key is recoverable, loss of an uncooperative non-Google-managed app signing key is not.

8. Build and Upload Pipeline

# Release build
./gradlew bundleRelease

# Upload with Gradle Play Publisher or Fastlane
bundle exec fastlane supply --aab app/build/outputs/bundle/release/app-release.aab \
  --track internal --release_status completed

Common CI: GitHub Actions, Bitrise, Codemagic, Firebase App Distribution for pre-release builds.

9. Staged Rollout

Always use a staged rollout for production: 5% -> 10% -> 20% -> 50% -> 100%, with a day or more between steps.

• Monitor crash-free users per cohort (see staged-rollouts).
• Use the Halt rollout control in Play Console if crash-free users drop below your SLO; this stops new installs from receiving the version.
• Pair with server-side feature flags for in-app kill switches.

10. Pre-Launch Report

Play runs automated crawlers against your AAB in lower tracks. Review the pre-launch report before promoting:

• Crashes on specific devices or Android versions.
• Accessibility issues.
• Security warnings (cleartext traffic, weak crypto).
• Performance (startup time, FPS).

11. Common Rejection Reasons

• Permissions mismatched with declared functionality.
• Data Safety form missing a known SDK.
• Deceptive behavior (fake reviews, misleading ads).
• IP claims on icons or screenshots (other brands without permission).
• Account deletion not offered.
• targetSdk below the policy threshold.

12. Anti-Patterns

• Single-step rollout to 100%.
• Upload key committed to repo.
• Ignoring pre-launch report warnings.
• Adding a new SDK without updating Data Safety form.
• Missing foreground service types on API 34+.
• Account deletion behind support email only.

Checklist

• AAB upload, signing by Google Play enabled, upload key stored securely.
• targetSdk meets current Play policy.
• Data Safety form matches current SDK inventory; account deletion path exists.
• Runtime permissions + foreground service types declared correctly.
• Store listing complete per locale with privacy policy URL.
• Build has been on internal/closed testing before production.
• Staged rollout configured with halt criteria.
• Pre-launch report reviewed.
• New-developer closed-test-for-14-days policy satisfied where applicable.
• Sensitive permission declarations filed in Play Console.