How to Update an App on Google Play
Shipping an update is not the same job as shipping a first release. The listing, the store description and the reviews stay where they are and only the build changes. Because the package ID stays the same, the update installs over the app already on the phone, and the data the app keeps in its own private storage is preserved.
Most failures here are not code failures. They are three mistakes: uploading a versionCode that has already been used, signing the build with a key that does not match the published one, and expecting a halted rollout to work backwards onto phones that already received it. The order below avoids all three.
What changes between two versions of an app
The build changes, the identity does not. Keep the package ID and the signing key exactly as they are and raise the versionCode. Play takes new apps and updates as an Android App Bundle rather than an APK, so the artifact you produce this time is a bundle. If the app predates App Bundles, read the release page first, because the console states which format it accepts.
versionCode and versionName are different jobs
versionCode is an integer Play compares against everything you have uploaded, and it has to go up every time, including a test upload to a closed track. versionName is the string a user reads on the store page, such as 2.1.0, and Play does not order builds by it. A build with versionName 2.1.0 and versionCode 12 is older to Play than one with versionName 1.9.9 and versionCode 13. When you see the version code has already been used, raise the integer and build again.
Keep the package ID and the signing key identical
Android installs an update over an existing app only when the signing certificate matches the one on the device. A different package ID becomes a second app beside the old one, and a different key means the update is refused. Either way, existing users never receive it.
With Play App Signing, Google holds the app signing key and your keystore is the upload key that the bundle must be signed with. A lost upload key can be reset, so the listing survives. Without Play App Signing, a lost keystore means no further updates under that package ID. Back the keystore and its passwords up somewhere other than the build machine.
Build the bundle with a higher version code
Raise versionCode where the project defines it, usually the app's Gradle file or the template that generated it, then read the value out of the finished artifact: bundletool and aapt both print it. Check the target API level requirement in Play Console before the build starts, because a bundle below the current minimum is refused at upload with a message naming the level you need.
Create the release in Play Console
Open the app, go to Test and release, choose Production, then Create new release. Upload the bundle, let Play read the version code from it, and add release notes for the languages that matter. Read the review summary before continuing, because it flags a reused version code, a signing mismatch, a target API problem and incomplete app content declarations. If managed publishing is switched on, saving does not publish the release.
Staged rollouts, and why they are cheap insurance
A staged rollout sends the update to a percentage of users instead of everyone. One or five percent for a day shows what Android vitals says about crashes and ANRs with a small blast radius, then you widen to twenty, fifty and full. Play chooses who is in each slice.
Halting a rollout stops more devices receiving the build, but phones that already updated keep it, and there is no downgrade path. The fix is a new bundle with a higher version code, rolled out normally.
When to use internal or closed testing instead of production
The internal testing track delivers a build in minutes to a short list, which makes it the right place to prove that an update installs over the previous version and that stored data survives. Closed testing suits a wider group of real users and, on a new personal account, it is the only track that counts toward production access. Both are also the sensible route for a new permission, a database migration, or a rewrite of the sign-in flow.
Review time, and what happens to a phone that already has the app
An update review is usually quicker than a first release: many clear within hours, a couple of days is normal, and changes touching sensitive permissions, payments or health data can take longer. After approval, Play updates the app in the background where automatic updates are allowed, and otherwise shows an Update button on the store page. Existing installs keep their data, sessions and files, because the update replaces the app in place.
The Play Console messages to read before you roll out
Read the review summary instead of clicking past it. The lines that matter are a reused version code, a signing certificate that does not match the previous release, a target API level below the current requirement, stale app content declarations such as data safety, content rating and target audience, a pre-launch report listing crashes on real devices, and a managed publishing setting holding the release back. A previously halted rollout also shows as a state that a new release clears.
Rebuilding without redoing the whole setup
Built through apkbuild.org, the mechanics above are handled per project: each build raises the version code and signs with the same per-project keystore, so a rebuild installs over the version already on the phone, and the keystore can be downloaded and kept. Leave the package ID unchanged between builds.
Step-by-step
- Confirm what is published: In Play Console, note the package ID, the highest version code used so far and the signing key. Your next build must match the first and third and beat the second.
- Raise the version code: Increase versionCode by at least one. Change versionName only for a different label on the store page; it does not make the build newer.
- Rebuild the app as a bundle: Produce an .aab signed with the same keystore as the previous release, or the same upload key under Play App Signing, and check the target API level requirement first.
- Verify the artifact: Read the version code and certificate out of the bundle, then install it over the current version on a test device to confirm it replaces the app and keeps its data.
- Create the new release: In Play Console, open Test and release, then Production, choose Create new release, upload the bundle and add release notes. Fix every warning in the review summary.
- Choose the rollout path: Start a staged rollout at one to five percent, or send the build to the internal or closed track first when the change is risky.
- Watch vitals during the rollout: Watch Android vitals, the crash and ANR reports and reviews on the new version. Widen the percentage only when those numbers match the previous version.
- Fix forward if something breaks: Halt the rollout to stop further devices receiving it, then publish a new bundle with a higher version code. Installs that already updated cannot be moved back.
Frequently asked questions
Do I have to increase versionCode, or is versionName enough?
versionCode only. Play refuses a bundle whose version code has already been used, and it ignores versionName when deciding which build is newer. Raise the integer on every upload, including test uploads to a closed track, and change versionName when you want a different label on the store page.
Can I update an app with a different package ID?
No. A different package ID is a different app: it gets its own listing and installs beside the existing one rather than updating it. There is no way to move existing users across.
What happens if I lose the signing keystore?
If Play App Signing is on, your keystore is only the upload key and Google can help you reset it, so updates keep working. If Play App Signing is off and the app signing key is gone, you cannot publish another update under that package ID, because the new build's certificate will not match the installed app.
Can I roll back to an earlier version on Google Play?
You can halt a staged rollout so fewer devices receive the new build, but you cannot push an older version onto phones that already updated. Recovery means publishing a new bundle with a higher version code that fixes the problem.
How long does an app update review take?
Usually less than a first release. Many updates clear within hours and a couple of days is normal; updates touching sensitive permissions, payments or health data can take longer. The rollout percentage applies after review, not during it.
Do users lose their data when an app updates?
Not from the update itself. Because the package ID and signing key stay the same, Android replaces the app in place and private app data is kept. Data loss in practice comes from a bug in a migration you shipped, or from a user uninstalling and reinstalling.
Why does Play say the version code has already been used?
Because a bundle with that version code, or a higher one, has already been uploaded for this app. Raise the integer, rebuild and upload again. Deleting the earlier release does not free the number.
Can I publish app updates without Android Studio?
Yes, if you have something that produces a signed bundle with the right package ID, version code and keystore. A build service can do that from a URL, a ZIP or a repository, and the release work in Play Console is the same either way.