INSTALL_FAILED_UPDATE_INCOMPATIBLE, with the supplied signature-mismatch message Package <package_name> signatures do not match the previously installed version; ignoring!, means Android rejected the incoming APK as an unauthorized update to an existing package. This occurs during APK deployment through Android Studio, ADB, physical devices, emulators and other package installers. The safest first action is to leave the existing installation intact while you verify the target device, package, Android user and incoming signing certificate.

What INSTALL_FAILED_UPDATE_INCOMPATIBLE means

Android identifies an update using both the application ID, also called the package name, and its authorized signing identity. An APK can update the existing application only when the application ID matches and the signing certificate matches the installed app, or when a valid proof-of-rotation establishes an authorized signing history. This requirement is documented in Android’s app update requirements.

The exact installer wording can vary by installer and Android build. Official Android documentation establishes the certificate rule but does not publish one universal installer message for every build.

Common confirmed contexts include a debug APK replacing a release build, a local APK replacing a Google Play-delivered build, a prior installation on the selected emulator or device, or package state belonging to another Android user or work profile. A valid version code is still required for a normal update, but it cannot authorize a different signing certificate.

Verify the target device, package and Android user

Do this before changing signing settings or removing anything. Replace SERIAL, USER_ID and PACKAGE_NAME only with values you have verified.

  1. Run adb devices -l.
  2. Identify the intended physical device or emulator and record its serial.
  3. Confirm the application’s exact application ID or package name.
  4. Query that package for the relevant user with adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.

Serial-scoped commands matter when multiple devices or emulators are connected. The official ADB documentation describes target selection and the package-manager operations used here.

Expected result: the query either identifies existing package state for that user or returns no matching package. An empty result for the primary user does not prove that every secondary user or managed profile is clear; check those contexts separately before uninstalling anything.

Risk and rollback: these commands inspect targets and package state without intentionally removing the app. If the serial, package name or user is uncertain, stop rather than proceeding with a destructive command.

Inspect the incoming APK’s signing certificate

Inspect the APK you are actually trying to deploy:

  1. Run apksigner verify --print-certs app.apk.
  2. Compare the printed certificate with the application’s known authorized signing configuration where access permits.
  3. If the certificates differ and no valid signing lineage applies, stop the update attempt.

The relevant identity may be a debug certificate, a locally managed release certificate or the app-signing certificate used for a Play-distributed build. An upload certificate is not necessarily the certificate used to sign APKs delivered by Google Play. The Android app-signing documentation explains certificate comparison and the app-signing versus upload-key distinction.

Android 9 and later support APK Signature Scheme v3 proof-of-rotation. A valid rotation lineage can authorize a newer certificate, but merely generating or selecting a different key does not. Access to an installed APK or its certificate can also be restricted, so the installed identity may need to be confirmed against known release records rather than inferred.

Expected result: you establish whether the incoming APK uses the authorized app-signing identity or valid lineage. Certificate inspection does not modify the installed app.

Preserve app data by rebuilding with the authorized signing identity

When this applies: use this preferred path when the existing installation and local data must remain, the application ID is unchanged, and you control the correct app-signing key or valid rotation process. The incoming versionCode must not be lower than the installed version.

Prerequisites:

  • The intended serial, user and package name have been verified.
  • You have access to the established app-signing configuration or valid proof-of-rotation.
  • You have not removed the existing installation.
  1. Run adb devices -l and select the intended serial.
  2. Run adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  3. Inspect the incoming APK with apksigner verify --print-certs app.apk.
  4. Build the APK using the established app-signing configuration.
  5. Install it on the selected target with adb -s SERIAL install -r app.apk.
  6. If the certificates differ, stop. Do not expect a version-code change, cache clearing or a clean build to authorize the update.

Expected result: Android accepts the APK as an authorized update if its application ID, version requirements and signing identity or valid lineage satisfy the update checks. This cannot be guaranteed without verifying the device-specific package state.

Risk and rollback: risk is low because the existing package is retained. If installation is still rejected, keep the current installation and rebuild with the authorized signing configuration rather than substituting a new private key.

Handle a Google Play-installed app

When this applies: use this path when the installed copy came from Google Play and your local APK is signed with an upload key or another local key.

Prerequisites: Play App Signing is enabled, and you have access to an approved test track, Internal App Sharing or Play-generated release artifacts.

  1. Confirm whether Play App Signing manages the distributed app-signing key.
  2. Do not compare the installed app only with the upload-key certificate; the upload key and distributed app-signing key can be different.
  3. Use Internal App Sharing to test what Google Play delivers, or download Play-generated APK artifacts.
  4. For locally downloaded split APKs, use adb install-multiple as documented.
  5. Use a locally signed APK only if it has the same authorized app-signing identity.

For Play signing-key upgrades, Android 13 and later can receive APKs signed with the upgraded key, while earlier Android versions receive updates signed with the older key.

Expected result: the test artifact is distributed with a signing identity compatible with the installed Play version. An upload-key match alone is not evidence of compatibility.

Risk and rollback: risk is low when the Play-installed app remains in place. Retain it and return to the appropriate Play testing path if the local artifact cannot be authorized.

Check secondary users, work profiles and managed devices

When this applies: use this diagnostic path when the app appears absent in the primary profile or the device has secondary users, a work profile, a managed profile or Secure Folder-like package isolation.

Prerequisites: USB or wireless debugging access and permission to inspect the device. Enterprise policy can limit visibility and package operations.

  1. Select the intended target using adb -s SERIAL.
  2. List its users with adb -s SERIAL shell pm list users.
  3. For each relevant ID, run adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  4. Use the verified user ID explicitly in later package-manager commands.
  5. If an enterprise profile controls the package, use the organization’s approved administrator path.
  6. Do not attempt to bypass device-policy restrictions.

Expected result: you identify whether the conflicting package state belongs to another user or profile. Profile isolation can make an application invisible from the primary profile, but this remains a possibility to verify rather than a presumed cause.

Risk and rollback: inspection is non-destructive, but profile ownership and visibility vary. Stop if policy or ownership is unclear; no rollback is needed for the listed inspection commands.

Remove a conflicting test installation only if its data is disposable

Data-loss warning: uninstalling can delete the app’s local data. Reinstalling restores the app binary, not deleted data. Continue only for a disposable test installation or after explicitly accepting the loss and verifying any independent backup you need.

When this applies: use this destructive fallback only when preserving the existing installation is unnecessary or the correct authorized signing identity is unavailable and a fresh installation is acceptable.

Prerequisites:

  • The serial, package name and user scope are verified.
  • Required test data has been exported to an independent location or is known to be disposable.
  • The package is not subject to an unapproved managed-profile removal.
  1. Confirm the target with adb devices -l.
  2. Confirm the package and user with adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  3. For one user, run adb -s SERIAL shell pm uninstall --user USER_ID PACKAGE_NAME.
  4. Install the replacement APK after removal.
  5. Recreate or restore only data available from an independent, usable backup.

Warning: without --user, pm uninstall removes the package for all device users by default. Do not omit the user scope casually.

Expected result: the replacement is treated as a fresh installation for the selected user rather than an update to the conflicting installation.

Risk and rollback: risk is high. Reinstalling can restore the binary but cannot recover deleted local data unless a separate backup exists and is usable.

What will not fix this error and how to rule out other install failures

  • Incrementing versionCode: required where normal update rules demand it, but it cannot authorize an APK signed by a different certificate.
  • Clearing Gradle caches: this does not change the APK’s signing identity.
  • Cleaning and rebuilding without correcting signing: rebuilding helps only if it restores the authorized signing configuration.
  • Clearing app storage or deleting visible files: this does not change the package’s authorized signing identity.
  • Comparing only the Play upload key: the Play-distributed APK may use a different app-signing certificate.
Error Narrow distinction
INSTALL_FAILED_UPDATE_INCOMPATIBLE The existing package and incoming APK do not have an authorized signing relationship.
INSTALL_FAILED_VERSION_DOWNGRADE The incoming version is lower; this is not the certificate-conflict diagnosis covered here.
INSTALL_FAILED_INVALID_APK The installer considers the APK invalid rather than an unauthorized signed update.
INSTALL_FAILED_INSUFFICIENT_STORAGE The installation lacks available storage rather than a compatible signing identity.

Resolution is verified when the intended target accepts the APK as an authorized update, or when a deliberately removed disposable installation accepts it as a fresh install. If installation succeeds but the application later reports an unrelated file-sharing runtime exception, use How to fix android.os.FileUriExposedException on Android instead.