Your upload was rejected because its version code is one Google Play has already received for that app. The fix is to raise the version code above the highest one you have ever uploaded, rebuild, and upload the new bundle.
The message usually reads: "Version code 1 has already been used. Try another version code." It is one of the most common upload errors during closed testing, because that is when most developers upload several builds in a short time.
Version code and version name are not the same
Every Android build has two version values. The version name, such as 1.0.2, is what users see on the Play Store. The version code is a whole number that only Google Play and Android use to tell builds apart.
Google Play only checks the version code. You can upload 1.0.0 and then 1.0.0 again as long as the second one has a higher version code, and you can't upload 2.0.0 if its version code was already used.
Why it says used when you deleted the release
A version code is taken the moment a bundle is uploaded, not when a release goes live. Discarding a draft release, removing a release from a track or uploading to a different track doesn't free it. Codes are shared by all tracks of the same app, so a build you uploaded to internal testing blocks that number for closed testing and production too.
To see the highest code Play Console knows, open your app in Play Console and look in App bundle explorer. It lists every bundle uploaded for the app with its version code. Your next upload needs a number higher than the top one there.
If you want the same build on another track, you don't need to upload it again. When you create the release, add the existing bundle from your library instead.
Where to change it in your project
Native Android: open app/build.gradle or build.gradle.kts and raise versionCode in the defaultConfig block. React Native uses the same field in android/app/build.gradle.
Flutter: the version code is the number after the plus sign in pubspec.yaml. In version: 1.0.0+3 the version code is 3, so change it to 1.0.0+4. You can also pass --build-number to flutter build appbundle. If the old number still ends up in the bundle, run flutter clean and build again.
Expo: set android.versionCode in app.json or app.config.js. If you build with EAS, it can also increase the number for you on each build.
Unity: open Player Settings, then Other Settings, and raise Bundle Version Code before building the app bundle.
Make sure the new bundle really has the new code
If you raised the number and still get the error, the file you uploaded is probably an old build. Check the date of the bundle, or open it in Android Studio with Build, Analyze APK, which shows the version code of the file.
In CI, a common cause is a version code fixed in the build file while the pipeline uploads a new bundle on every run. Many teams use the CI run number as the version code so it always goes up on its own.
Don't jump to a huge number to be safe. Google Play has a maximum version code, and every future upload has to be higher than your current one, so plain steps of one are the easiest to live with.
Uploading a new build during closed testing
Fixing a bug and uploading a new build during your 14-day closed test is normal, and opted-in testers get the update through the Play Store. What matters for the requirement is that 12 or more testers stay opted in every day.
If you need those testers, PeerPlay is a free way to find them: Android developers test each other's apps every day through your real closed track, so each new build you upload reaches real phones.
Top comments (0)