versionCode vs versionName: Preventing Play Upload and Update Errors

Give each field one job

A label such as 2.10 does not make an APK newer than one labelled 2.9 if its version code does not advance. Renaming an APK has no effect on either packaged field. Android versioning.

Set values in the application module

An illustrative Kotlin DSL fragment is:

android {
    defaultConfig {
        versionCode = 42
        versionName = "2.3.0"
    }
}

These values are examples, not a recommended starting number for an existing app. Product flavors and automation can override them; inspect the final variant rather than trusting the first defaultConfig block you find.

Verify the built artifact

Use metadata inspection before upload:

apkanalyzer manifest version-code app-release.apk
apkanalyzer manifest version-name app-release.apk

For AAB workflows, inspect the built bundle with bundle-aware tooling or generated APKs. Keep the version code associated with the signing record, source revision, mapping files and native symbols.

Handle a reused-code error correctly

If Play says a version code was already used, do not assume deleting a draft or renaming the file makes it available again. Generate a new authorized build with an appropriate higher code and submit that artifact. Review the current release workflow for the state of the affected release.

For multiple tracks, allocate codes deliberately so a tester can move between intended releases. A higher internal-test build can complicate expectations when returning to a lower-code production release.

Make rollback expectations explicit

A staged rollout can be halted, but publishing an older code is not the same as deploying a web rollback. Plan a corrective release with a valid code, preserved data compatibility and known signing identity.

APKLint's checker can expose packaged version information. It cannot reserve Play version codes, determine every account's release state or replace a release ledger maintained by your team.