Tutorials / Native Mac IDE / Re-upload an Android app to Play Console
📝 Written ● Beginner Updated 2026-05-13

Re-upload an Android app to Play Console

Ship a new version of your Android app to Google Play. Bump the version number, build a signed app bundle, upload, pick a release track. Walks through every tool you need to install — links for Mac, Windows, and Linux.

What you need (one-time)

0

If this is your first time, install these once. Skip whichever you already have.

Bump the version number

1

Google Play rejects re-uploads with the same versionCode. Open your app's build.gradle (or build.gradle.kts) — usually at app/build.gradle in your project — and bump it:

android {
    defaultConfig {
        versionCode 42       // bump this — must be unique & always increasing
        versionName "1.2.1"  // user-visible; bump on real changes (e.g. 1.2.0 → 1.2.1)
    }
}

What each one is:

  • versionCode — an integer Google uses internally. Must increase every upload. Goes 1, 2, 3, … 42, 43.
  • versionName — the string users see in the Play Store ("1.2.1"). Bump on real changes; can stay the same for tiny patch uploads.

Android versioning docs ↗.

Build a signed AAB

2

Google Play requires an AAB (Android App Bundle), not the old APK format. What an AAB is ↗.

Option A — Android Studio UI: Build → Generate Signed Bundle / APK → Android App Bundle → Next → choose keystore → Release → Finish. Output path is shown when it finishes.

Option B — terminal:

./gradlew bundleRelease

Output lands at app/build/outputs/bundle/release/app-release.aab.

First time only — set up a keystore. The keystore is the cryptographic identity of your app. Use Android Studio's Build → Generate Signed Bundle / APK → Create new… to make one, or run keytool -genkey -v -keystore release.keystore -alias my-app -keyalg RSA -keysize 2048 -validity 10000 in a terminal (keytool docs ↗). Store the file and password somewhere safe. Lose the keystore and you can never ship updates to this app again.
Use Play App Signing (recommended). Let Google manage your release signing key — enrolled once during your first upload. If you lose your upload key, Google can reset it. Enroll docs ↗.

Open Play Console

3

Sign in to Google Play Console ↗ with the Google account on your developer registration. Pick your app from the list.

Pick a release track

4

In the left sidebar under Testing and Production, you have four tracks:

  • Internal testing — up to 100 named testers; available in minutes; no human review for established apps. Start here.
  • Closed testing — named groups; Google review (~1–7 days).
  • Open testing — anyone with a link; review required.
  • Production — public release; full review (1–7 days).

For iterating, click Internal testing.

Create the release

5

Click Create new release. Drag your app-release.aab file into the upload area. Wait for Play Console to process it (~30 seconds).

Fill in Release notes (what changed for testers). Then Next → Save → Send for review. For internal testing, this is effectively instant.

Add testers (first time only)

6

On the internal testing page, click Testers. Either:

  • Create email list — paste tester emails (one per line).
  • Copy the opt-in URL at the bottom — share with testers; they click and join.

Testers download via the Play Store as if it were a normal app, after they accept the invitation.

Wait for review

7

Time depends on the track:

  • Internal testing: ~minutes. Usually no human review.
  • Closed / Open testing: 1–7 days for first build per track; subsequent often faster.
  • Production: 1–7 days. New apps and big changes take longer.

Google emails when status changes. Watch in Play Console under Publishing overview.

Promote between tracks (when ready)

8

When internal testing has been stable, promote to a wider track without re-uploading:

Play Console → release track → Promote release → pick target (Closed / Open / Production) → review changes → submit. Each promotion goes through the target track's review.

Use staged rollout for Production

9

For Production releases, don't hand 100% to users on day one. Use staged rollout:

  • Start at 10% or 25% of users.
  • Watch crash rates in Android Vitals ↗.
  • Ramp to 50%, then 100%, over a few days.
  • Halt the rollout if Vitals shows regressions.

Optional: CI uploads with fastlane

10

For automating uploads from a CI pipeline (GitHub Actions, etc.), use fastlane ↗. Install:

brew install fastlane            # macOS
# or: sudo gem install fastlane (Linux/Windows)

Generate a service account JSON in Play Console (Setup → API access → Create new service account), grant it Release manager on your app, then:

fastlane supply --aab app-release.aab \
  --track internal \
  --json_key path/to/service-account.json

References: fastlane supply ↗ · Play Developer API ↗.

Common rejection reasons: missing required permission justifications · target SDK version too low (Google bumps the floor annually — current requirements ↗) · incomplete Data safety form · broken sign-in flow during Google's automated testing. Most are fixable without a new upload — just update the metadata.

Official references

What's next

Re-upload an iOS build to TestFlight

Same shape, Apple side

Create and run your first Android emulator

Test your build locally before uploading

Redeploy a website

Web equivalent — much faster turnaround than mobile review