How to roll back an Android app version

An update lands, something you relied on is gone or broken, and you want the previous build back. It is one of the few genuinely good reasons to install an APK by hand. It is also more awkward than it first appears, and the awkwardness is worth understanding before you start rather than halfway through.

Android will not downgrade in place

Every build carries a version code: an integer that only ever goes up. It is not the version name — the app might call itself 4.2.1 in the interface while its version code is 40201, or 87, or anything the developer chose. The integer is what the system compares.

Install a lower version code over a higher one and you get INSTALL_FAILED_VERSION_DOWNGRADE. There is no user-facing setting for this and no way to talk the package manager out of it. Updates go forward.

Which means uninstalling first, which means losing the data

The only route on an ordinary device is to uninstall the current version and install the older one fresh. Uninstalling removes the app's private data directory with it: accounts, settings, local content, everything that was not synced somewhere else.

So the first step is not the uninstall. It is getting your data out. Use whatever export the app itself provides — most apps that hold anything worth keeping have one, buried in settings. If it syncs to an account, confirm the sync has actually completed rather than assuming it. Do not plan around adb backup: it has been deprecated for years, most apps opt out of it, and on modern versions it produces empty or unusable archives more often than not. There is no general-purpose way to preserve app data across a reinstall on an unrooted device, and discovering this after the uninstall is a bad time to discover it.

Get the right file

You need the specific older build, and two properties of it matter.

First, the signing certificate. After an uninstall there is no existing certificate to conflict with, so any signed APK will install — including a repackaged one. The certificate check that would normally protect you is exactly what you just removed, which makes the rollback moment the most exposed one in this whole procedure. Check the fingerprint against the build you were running, and check the SHA-256 against a published hash, before you install.

Second, splits. Apps delivered from Play as app bundles arrive as several APKs — a base plus configuration splits for your device's screen density, CPU architecture and language. A lone base.apk from elsewhere may install and then crash on launch looking for resources that are not there. If the build was distributed as a bundle, you need either a universal APK or the full set, installed together with adb install-multiple. This is the step that most often turns a five-minute rollback into an evening.

Doing it

# 1. export your data from inside the app first — this is not reversible
# 2. uninstall the current version
adb uninstall com.example.app

# 3. install the older build
adb install ./app-4.2.1.apk

# or, if it came as a bundle:
adb install-multiple ./base.apk ./split_config.arm64_v8a.apk ./split_config.xxhdpi.apk

You can do steps two and three from the phone itself, of course — uninstall from App info, then open the APK in a file manager. adb is simply easier to get right and tells you why it failed when it does.

Then stop Play from undoing it

If the app is on Play and auto-update is on, it will quietly update straight back to the version you just spent an hour removing. Open the app's Play listing, use the overflow menu, and switch off auto-update for that app specifically. Do not turn auto-update off globally — that fixes one app by making every other app on your phone worse.

This only applies if the build you installed shares its signing certificate with the Play version. If you installed the developer's own build and Play's copy is signed by Google under Play App Signing, Play cannot update it at all and the setting is moot.

Treat this as temporary

A pinned old version stops receiving security fixes on the day you pin it. That may be a perfectly reasonable trade for a week while a bug gets fixed upstream. It is a bad permanent arrangement, and it becomes one by default, because nothing will ever remind you.

So give it a deadline when you set it up. Note the version you are avoiding, check back when the next release ships, and get back onto the current build as soon as the thing that broke is fixed. Rolling back is a stopgap. The goal is still to be current.

One flag you will read about, and why it will not help

The adb install command has a -d flag documented as allowing version downgrade. It works only for debuggable builds — apps compiled with the debuggable flag set, which release builds are not. Every APK you would actually want to roll back is a release build, and the flag will be ignored. It is a genuine feature; it is just a feature for developers testing their own app, not a way around the rule.