Debugging log · Install

INSTALL_FAILED_UPDATE_INCOMPATIBLE — the key changed

I tried to install a build on a test device and Android flatly refused it. The app was already there, the package name matched, the version was newer — and it still wouldn't go on. The error told me everything if I'd known how to read it: the copy on the device and the APK in my hand were signed with different keys.

The short version: Android only lets an app be replaced by a build signed with the same key. If the signature differs — even by accident — the install is blocked. Either sign with the original key, or uninstall the old copy first (which wipes its data).

The error

adb: failed to install app-release.apk:
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE:
Existing package com.example.app signatures do not match
newer version; ignoring!]

Sometimes it shows up as INSTALL_FAILED_VERSION_DOWNGRADE instead if you also went backwards in version code, but the signature line is the one that matters here.

Why Android is so strict about this

The signing key is the app's identity. It's what proves a new APK came from the same developer as the one already installed — and therefore that it's safe to hand over that app's stored data, permissions and identity. If any APK with a matching package name could overwrite yours, a malicious app could impersonate your banking app and inherit its data. So the rule is absolute: same package name and same signature, or no update.

How it usually happens

Debug build over a release build (or vice versa). Debug APKs are signed with the auto-generated debug key; release ones with your keystore. Different keys.
A Play-installed app, then a local build. With Play App Signing, Google signs the APK users get; your local build is signed with the upload/debug key. They won't match.
Building on a different machine. Android Studio generates a debug keystore per machine, so your laptop's debug key differs from your desktop's.
A new keystore. You regenerated one, or a teammate signed with theirs.

Fixes

1. Uninstall first (the usual answer for testing)

If it's a test device and you don't care about the app's data:

adb uninstall com.example.app
adb install app-release.apk

Note that this deletes the app's data. If the point of your test was to check an upgrade path, this defeats it — see the next option.

2. Sign with the original key

To genuinely test an update over an existing install, the new APK must carry the same signature. Build with the same keystore that signed what's on the device. If the device has the Play version, install a build signed with the app signing key — Play Console can give you a testable artifact for that, rather than you shipping your upload key around.

3. Keep debug and release apart

Give your debug builds a different package name so both can live on the device at once and never collide:

android {
    buildTypes {
        debug {
            applicationIdSuffix = ".debug"
        }
    }
}

Now the debug app is com.example.app.debug — a different package entirely, so it installs alongside the real one and this error stops happening during development.

Don't "fix" this by changing your release keystore. The signature is what lets you update your published app; swapping it means existing users can't update at all. If you've genuinely lost the key, the recovery path runs through Play Console, not through re-signing.

How to check the signature yourself

If you're not sure which key an APK carries, inspect it:

apksigner verify --print-certs app-release.apk

Compare the certificate fingerprint with the one on the device build (or with the app signing certificate shown in Play Console). If the fingerprints differ, you've found your answer.

Package names and file names above are placeholders — use your own.