Skip to content
All articles

“Signature mismatch” means stop, not troubleshoot

The workaround at the top of every search result is the one thing you should not do. Here is what the error means, what causes it innocently, and how to tell the difference.

Security6 min read

Sooner or later an install fails with something like INSTALL_FAILED_UPDATE_INCOMPATIBLE, or the friendlier phrasing your launcher shows: “App not installed as package conflicts with an existing package.” Search for it and you will find the same advice everywhere: uninstall the old one first, then it works.

It does work. That is the problem.

What the device is telling you

There is already an app on this device with the same package name, and it was signed by a different key than the file you are trying to install.

Android takes that seriously because the package name is an app's identity — it is what decides which private data directory the app opens, which permissions it inherits, and which stored credentials it can reach. If any file could claim any package name, an app called anything at all could inherit your banking app's session by claiming to be an update to it. The certificate check is what stops that. Same package name plus a different signer means the request is refused, every time, with no override.

The fix that isn't

Uninstalling the existing app removes the certificate that was blocking the install. The new file then goes on cleanly, because there is nothing left to conflict with.

Read that again in terms of what actually happened. You had an app from a known author. Android told you the new file came from somebody else. You removed the app — and its data along with it — so the new file could take its place, its package name, and its permissions. The error was the entire protection. The workaround is a procedure for disabling it.

The boring explanations

Most mismatches are not attacks. The usual causes:

You are crossing distribution channels. The Play build and the developer's own build of the same app can be signed with different keys, because Google signs Play deliveries for apps enrolled in Play App Signing. Both are genuine. Neither can update the other.

You are looking at a fork or an independent build. F-Droid, for instance, compiles from source and signs with its own key. Same package name, same source code, different signer — and no path from one to the other without an uninstall.

You previously installed a modified build. If a repackaged copy got there first, the legitimate app is now the one that cannot install.

The developer rotated keys without a lineage, or you are holding a debug build signed with the default debug key rather than a release build.

The alarming one

Someone took the real APK, added code to it, and re-signed it. They had to re-sign it: they do not have the developer's private key, and any change to the file invalidates the original signature. So the repackaged copy has the same package name, the same icon, the same version string, and a different certificate.

That certificate mismatch is the only mechanical difference between the real app and the hostile one. Everything a user looks at can be copied exactly. The fingerprint cannot. And the mismatch error is precisely what a search result will tell you to work around.

Telling them apart

Compare the fingerprints instead of guessing. Pull the installed copy off the device and print both certificates:

adb shell pm path com.example.app
package:/data/app/~~xyz==/com.example.app-abc==/base.apk

adb pull /data/app/~~xyz==/com.example.app-abc==/base.apk installed.apk
apksigner verify --print-certs installed.apk
apksigner verify --print-certs new-download.apk

Compare the two SHA-256 digests. If they match, the failure was something else entirely and you have not learned anything alarming. If they differ, you now have a concrete question: which of these two authors did you mean to trust? Answer it before you uninstall anything.

If you decide to proceed anyway

Sometimes the answer is legitimately “yes, I meant to switch” — moving from a Play build to an F-Droid build, or from an official build to a fork you have chosen deliberately. In that case: export whatever data you need first, because the uninstall will take it with it, and there is no supported way to carry app data across a signer change on an unrooted device.

The rule is not “never uninstall.” The rule is that you should be able to name the other author before you do. If your reason is “the internet said this fixes it,” you do not have a reason. Signature mismatch is one of the very few places where Android is unambiguously on your side, and it is worth letting it win.