Debugging log · Play Console

"Version code already used" on a Play upload

I built a release, went to upload the AAB, and Play Console bounced it immediately: the version code has already been used. The build was fine — I'd just forgotten the one number Play uses to tell two builds apart. It's a thirty-second fix, but it's confusing the first time because the number it complains about isn't the version your users see.

The short version: every build you upload must have a versionCode higher than any you've uploaded before — to any track, including ones you deleted. Bump the number and re-upload. Then automate it so you never hit this again.

The error

Version code 7 has already been used. Try another version
code.

versionCode vs versionName

Your app has two version values and they do different jobs:

versionCode — an integer Play and the system use internally to order builds. Users never see it. It must strictly increase with every upload.
versionName — the human string (1.4.2) shown on the store listing. It can be anything and isn't what this error is about.

The error is purely about the integer. You can ship the same versionName twice if you really want, but never the same versionCode.

The fix — bump the integer

In your module's build.gradle, raise versionCode to something higher than anything you've uploaded:

android {
    defaultConfig {
        versionCode = 8      // was 7
        versionName = "1.4.2"
    }
}

Rebuild and re-upload. That's the whole fix for the immediate block.

Why "but I deleted that release"

The number that trips people: a version code is burned permanently the moment it's uploaded, even to a closed or internal track, and even if you later delete that release or that track. Play remembers every code it has ever seen for your app and refuses to reuse one. So "I removed that build, why is 7 still taken?" has a simple answer — uploading, not publishing, is what consumes the number. Always move up, never try to reclaim a code.

Stop hitting it — automate the bump

Forgetting to increment is the actual root cause, so remove the manual step. A common approach ties the code to something that always moves, like a CI build number:

versionCode = (System.getenv("BUILD_NUMBER")?.toInt()) ?: 1

Or keep a simple incrementing integer you bump as part of your release routine. The method matters less than making "the number always goes up" automatic rather than a thing to remember at the worst moment — right when you're trying to ship.

Pick a scheme and stick to it. Mixing a manual code on one release and a CI-derived one on the next can accidentally produce a lower number, which fails the same way. Whatever generates the code, make sure it only ever increases.

Related gotchas

Multiple AABs / split configs: each artifact in a release needs its own ascending code if you ship more than one.
Flavors: different product flavors can share the version logic but still must not collide on the same uploaded code.
Downgrades: you can't upload a code lower than the current production one and expect it to roll out — it's the same strictly-increasing rule.

Version numbers above are examples — set your own, higher than your last upload.