Version Code & Version Name: Rules, Collisions, and Cross-Track Behavior

The version code is an integer Play uses to decide which release is newer — and it's the single number that must always go up, across every track, for every upload. Confusing it with the human-readable version name, or bumping it inconsistently across tracks, is why testers pull down the wrong build and why uploads get rejected.

Version code vs version name

Only the version code drives upgrade and track-selection logic. The version name is purely informational — a higher versionName with a lower versionCode will never reach users as an update.

Where collisions happen

• Reusing a version code after a rollback or a discarded draft — Play sees the same code twice and rejects the second upload.
• Shipping a hotfix to production at 44 while a closed test at 43 is still promoted — testers would get the lower code from the wrong track.
• Forgetting that internal, closed, open, and production all share one version-code namespace on the account.

Checking your codes before you upload

1. 1

   Read the value in your source

   Check build.gradle (versionCode property) or read android:versionCode from AndroidManifest.xml after merging.

1. 1

   Compare across tracks

   In Play Console, open each track's release page and note the latest version code. Your new upload must be higher than the max across all of them.

1. 1

   Bump once, everywhere

   If you promote a build across tracks, keep the same version code — don't rebuild with a new one unless you're shipping new changes.