Give each field one job
| Field | Intended role |
|---|---|
versionCode |
Integer identifying a release in update and store workflows |
versionName |
Human-readable version string shown to users |
| Application ID | Stable installed and store identity |
| Source revision | Engineering traceability back to the code |
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.
Allocate codes across parallel release work
Imagine production uses code 120 and an internal tester has already installed code 125 from an upcoming feature branch. A corrective production build with code 121 can be valid for ordinary production users while not behaving like an upgrade on that tester's device. Keep the installation and track history in the support record before concluding that the new file is corrupt.
The Android versioning guide explains the update role of the integer code. Use an allocation method that avoids collisions between concurrent release jobs and respects the store's accepted range. A semantic version string, build timestamp in a filename or Git tag is useful traceability but does not replace the packaged integer.
Treat a corrective release as a new artifact
If a release needs a fix, produce a new candidate with an appropriate unused code, its own digest and matching diagnostic artifacts. Do not assume that replacing a file under the same download name changes what a store or device considers newer. Preserve the original published artifact for incident analysis.
Check the final code and name after flavor overrides and CI inputs have been applied. Record the command output from the actual distributable, and associate it with the mapping and native symbols created in that build. A mapping directory named after only the display version can collide when several candidates share that label.
Test update behavior over the intended prior release, including local database migrations and saved settings. A code increase satisfies one identity condition but says nothing about schema compatibility or signing continuity. For a planned rollback in behavior, build the corrected code path into a properly versioned new release and evaluate any data written by the intervening version. Keep the release ledger readable enough to answer which artifact a user received through a particular track. That operational record prevents a reused-code rejection, a testing-track mismatch and an actual application regression from being treated as the same problem.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
