INSTALL_FAILED_UPDATE_INCOMPATIBLE bedeutet zusammen mit der angegebenen Meldung über nicht übereinstimmende Signaturen Package <package_name> signatures do not match the previously installed version; ignoring!, dass Android das eingehende APK als nicht autorisierte Aktualisierung eines vorhandenen Pakets abgelehnt hat. Dies kann bei der APK-Bereitstellung über Android Studio, ADB, physische Geräte, Emulatoren und andere Paketinstallationsprogramme auftreten. Am sichersten ist es, die vorhandene Installation zunächst unverändert zu lassen und das Zielgerät, das Paket, den Android-Nutzer und das Signaturzertifikat des eingehenden APKs zu prüfen.

Was INSTALL_FAILED_UPDATE_INCOMPATIBLE bedeutet

Android erkennt eine Aktualisierung anhand der Anwendungs-ID, die auch als Paketname bezeichnet wird, und der autorisierten Signaturidentität. Ein APK kann die vorhandene Anwendung nur aktualisieren, wenn die Anwendungs-ID übereinstimmt und das Signaturzertifikat dem der installierten App entspricht oder wenn ein gültiger Rotationsnachweis eine autorisierte Signaturhistorie belegt. Diese Voraussetzung ist in den Anforderungen für Android-App-Updates dokumentiert.

Der genaue Wortlaut des Installationsfehlers kann je nach Installationsprogramm und Android-Build abweichen. Die offizielle Android-Dokumentation beschreibt die Zertifikatsanforderung, veröffentlicht jedoch keine einheitliche Meldung für alle Builds.

Zu den bestätigten typischen Situationen gehören ein Debug-APK, das einen Release-Build ersetzen soll, ein lokales APK anstelle eines über Google Play bereitgestellten Builds, eine frühere Installation auf dem ausgewählten Emulator oder Gerät sowie ein Paketstatus, der einem anderen Android-Nutzer oder Arbeitsprofil zugeordnet ist. Für eine normale Aktualisierung ist weiterhin ein gültiger Versionscode erforderlich. Er kann jedoch kein anderes Signaturzertifikat autorisieren.

Zielgerät, Paket und Android-Nutzer prüfen

Führen Sie diese Prüfung durch, bevor Sie Signaturkonfigurationen ändern oder etwas entfernen. Ersetzen Sie SERIAL, USER_ID und PACKAGE_NAME ausschließlich durch Werte, die Sie überprüft haben.

  1. Führen Sie adb devices -l aus.
  2. Ermitteln Sie das vorgesehene physische Gerät oder den Emulator und notieren Sie dessen Seriennummer.
  3. Prüfen Sie die genaue Anwendungs-ID beziehungsweise den Paketnamen der App.
  4. Fragen Sie das Paket für den betreffenden Nutzer mit adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME ab.

Auf eine Seriennummer beschränkte Befehle sind wichtig, wenn mehrere Geräte oder Emulatoren verbunden sind. Die offizielle ADB-Dokumentation beschreibt die Auswahl des Zielgeräts und die hier verwendeten Paketverwaltungsvorgänge.

Erwartetes Ergebnis: Die Abfrage zeigt entweder einen vorhandenen Paketstatus für diesen Nutzer oder kein übereinstimmendes Paket. Ein leeres Ergebnis für den primären Nutzer beweist nicht, dass alle sekundären Nutzer oder verwalteten Profile frei von diesem Paket sind. Prüfen Sie diese Bereiche separat, bevor Sie etwas deinstallieren.

Risiko und Wiederherstellung: Diese Befehle prüfen Ziele und Paketstatus, ohne die App absichtlich zu entfernen. Wenn Seriennummer, Paketname oder Nutzer nicht eindeutig feststehen, brechen Sie ab, anstatt einen destruktiven Befehl auszuführen.

Signaturzertifikat des eingehenden APKs prüfen

Untersuchen Sie das APK, das Sie tatsächlich bereitstellen möchten:

  1. Führen Sie apksigner verify --print-certs app.apk aus.
  2. Vergleichen Sie das ausgegebene Zertifikat, soweit Ihre Zugriffsrechte dies erlauben, mit der bekannten autorisierten Signaturkonfiguration der App.
  3. Wenn sich die Zertifikate unterscheiden und keine gültige Signaturhistorie vorliegt, brechen Sie den Aktualisierungsversuch ab.

Bei der maßgeblichen Identität kann es sich um ein Debug-Zertifikat, ein lokal verwaltetes Release-Zertifikat oder das App-Signaturzertifikat eines über Google Play bereitgestellten Builds handeln. Ein Upload-Zertifikat ist nicht zwangsläufig das Zertifikat, mit dem die von Google Play ausgelieferten APKs signiert werden. Die Dokumentation zur Android-App-Signatur erläutert den Zertifikatsvergleich und den Unterschied zwischen App-Signaturschlüssel und Upload-Schlüssel.

Android 9 und höher unterstützen Rotationsnachweise nach APK Signature Scheme v3. Eine gültige Rotationshistorie kann ein neueres Zertifikat autorisieren. Das bloße Erzeugen oder Auswählen eines anderen Schlüssels reicht dagegen nicht aus. Der Zugriff auf ein installiertes APK oder dessen Zertifikat kann ebenfalls eingeschränkt sein. Daher muss die installierte Identität unter Umständen anhand bekannter Release-Unterlagen bestätigt werden, statt sie nur herzuleiten.

Erwartetes Ergebnis: Sie stellen fest, ob das eingehende APK die autorisierte App-Signatur oder eine gültige Signaturhistorie verwendet. Die Zertifikatsprüfung verändert die installierte App nicht.

App-Daten durch einen Neubau mit der autorisierten Signatur erhalten

Wann dieser Weg geeignet ist: Verwenden Sie diesen bevorzugten Weg, wenn die vorhandene Installation und ihre lokalen Daten erhalten bleiben müssen, die Anwendungs-ID unverändert ist und Sie über den richtigen App-Signaturschlüssel oder ein gültiges Rotationsverfahren verfügen. Der eingehende versionCode darf nicht niedriger als der der installierten Version sein.

Voraussetzungen:

  • Die vorgesehene Seriennummer, der Nutzer und der Paketname wurden überprüft.
  • Sie haben Zugriff auf die bestehende App-Signaturkonfiguration oder einen gültigen Rotationsnachweis.
  • Sie haben die vorhandene Installation nicht entfernt.
  1. Führen Sie adb devices -l aus und wählen Sie die vorgesehene Seriennummer aus.
  2. Führen Sie adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME aus.
  3. Prüfen Sie das eingehende APK mit apksigner verify --print-certs app.apk.
  4. Erstellen Sie das APK mit der bestehenden App-Signaturkonfiguration.
  5. Installieren Sie es mit adb -s SERIAL install -r app.apk auf dem ausgewählten Ziel.
  6. Brechen Sie ab, wenn sich die Zertifikate unterscheiden. Eine Änderung des Versionscodes, das Leeren von Caches oder ein sauberer Neubau autorisieren die Aktualisierung nicht.

Erwartetes Ergebnis: Android akzeptiert das APK als autorisierte Aktualisierung, wenn Anwendungs-ID, Versionsanforderungen und Signaturidentität beziehungsweise gültige Signaturhistorie die Aktualisierungsprüfungen erfüllen. Ohne Prüfung des gerätespezifischen Paketstatus lässt sich dies nicht garantieren.

Risiko und Wiederherstellung: Das Risiko ist gering, da das vorhandene Paket erhalten bleibt. Wenn die Installation weiterhin abgelehnt wird, behalten Sie die aktuelle Installation bei und erstellen Sie das APK erneut mit der autorisierten Signaturkonfiguration, anstatt einen neuen privaten Schlüssel zu verwenden.

Mit einer über Google Play installierten App umgehen

Wann dieser Weg geeignet ist: Verwenden Sie diesen Weg, wenn die installierte Version aus Google Play stammt und Ihr lokales APK mit einem Upload-Schlüssel oder einem anderen lokalen Schlüssel signiert ist.

Voraussetzungen: Die Play App-Signatur ist aktiviert und Sie haben Zugriff auf einen genehmigten Test-Track, die interne App-Freigabe oder von Google Play erzeugte Release-Artefakte.

  1. Prüfen Sie, ob die Play App-Signatur den verteilten App-Signaturschlüssel verwaltet.
  2. Vergleichen Sie die installierte App nicht ausschließlich mit dem Zertifikat des Upload-Schlüssels. Upload-Schlüssel und verteilter App-Signaturschlüssel können unterschiedlich sein.
  3. Verwenden Sie die interne App-Freigabe, um die von Google Play ausgelieferte Version zu testen, oder laden Sie von Google Play erzeugte APK-Artefakte herunter.
  4. Verwenden Sie für lokal heruntergeladene Split-APKs wie dokumentiert adb install-multiple.
  5. Verwenden Sie ein lokal signiertes APK nur, wenn es dieselbe autorisierte App-Signaturidentität besitzt.

Bei Upgrades des Play-Signaturschlüssels können Android 13 und höhere Versionen APKs erhalten, die mit dem aktualisierten Schlüssel signiert wurden. Frühere Android-Versionen erhalten dagegen Aktualisierungen, die mit dem älteren Schlüssel signiert sind.

Erwartetes Ergebnis: Das Testartefakt wird mit einer Signaturidentität verteilt, die mit der installierten Play-Version kompatibel ist. Eine Übereinstimmung des Upload-Schlüssels allein belegt keine Kompatibilität.

Risiko und Wiederherstellung: Das Risiko ist gering, solange die über Google Play installierte App erhalten bleibt. Behalten Sie sie bei und kehren Sie zum geeigneten Play-Testverfahren zurück, wenn das lokale Artefakt nicht autorisiert werden kann.

Sekundäre Nutzer, Arbeitsprofile und verwaltete Geräte prüfen

Wann dieser Weg geeignet ist: Verwenden Sie diesen Diagnoseweg, wenn die App im primären Profil nicht vorhanden zu sein scheint oder das Gerät sekundäre Nutzer, ein Arbeitsprofil, ein verwaltetes Profil oder eine Paketisolierung ähnlich dem sicheren Ordner verwendet.

Voraussetzungen: Sie benötigen Zugriff über USB- oder WLAN-Debugging und die Berechtigung, das Gerät zu prüfen. Unternehmensrichtlinien können die Sichtbarkeit und Paketvorgänge einschränken.

  1. Wählen Sie das vorgesehene Ziel mit adb -s SERIAL aus.
  2. Listen Sie dessen Nutzer mit adb -s SERIAL shell pm list users auf.
  3. Führen Sie für jede relevante ID adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME aus.
  4. Geben Sie die überprüfte Nutzer-ID in späteren Paketverwaltungsbefehlen ausdrücklich an.
  5. Wenn ein Unternehmensprofil das Paket verwaltet, verwenden Sie den von der Organisation genehmigten Administratorweg.
  6. Versuchen Sie nicht, Einschränkungen durch Geräterichtlinien zu umgehen.

Erwartetes Ergebnis: Sie ermitteln, ob der widersprüchliche Paketstatus einem anderen Nutzer oder Profil zugeordnet ist. Durch die Profilisolierung kann eine Anwendung im primären Profil unsichtbar sein. Dies ist jedoch lediglich eine zu prüfende Möglichkeit und keine automatisch feststehende Ursache.

Risiko und Wiederherstellung: Die Prüfung ist nicht destruktiv, Eigentumsverhältnisse und Sichtbarkeit unterscheiden sich jedoch je nach Profil. Brechen Sie ab, wenn Richtlinien oder Zuständigkeiten unklar sind. Für die aufgeführten Prüfbefehle ist keine Wiederherstellung erforderlich.

Widersprüchliche Testinstallation nur bei entbehrlichen Daten entfernen

Warnung vor Datenverlust: Durch die Deinstallation können die lokalen App-Daten gelöscht werden. Eine erneute Installation stellt die App-Dateien wieder her, nicht jedoch gelöschte Daten. Fahren Sie nur bei einer entbehrlichen Testinstallation fort oder nachdem Sie den Verlust ausdrücklich akzeptiert und eine gegebenenfalls benötigte unabhängige Sicherung überprüft haben.

Wann dieser Weg geeignet ist: Verwenden Sie diese destruktive Ausweichlösung nur, wenn die vorhandene Installation nicht erhalten bleiben muss oder die richtige autorisierte Signaturidentität nicht verfügbar und eine Neuinstallation akzeptabel ist.

Voraussetzungen:

  • Seriennummer, Paketname und Nutzerbereich wurden überprüft.
  • Benötigte Testdaten wurden an einen unabhängigen Speicherort exportiert oder sind nachweislich entbehrlich.
  • Das Paket unterliegt keiner nicht genehmigten Entfernung aus einem verwalteten Profil.
  1. Bestätigen Sie das Ziel mit adb devices -l.
  2. Bestätigen Sie Paket und Nutzer mit adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  3. Führen Sie für einen einzelnen Nutzer adb -s SERIAL shell pm uninstall --user USER_ID PACKAGE_NAME aus.
  4. Installieren Sie nach dem Entfernen das Ersatz-APK.
  5. Erstellen Sie ausschließlich Daten neu oder stellen Sie Daten wieder her, die in einer unabhängigen, nutzbaren Sicherung vorhanden sind.

Warnung: Ohne --user entfernt pm uninstall das Paket standardmäßig für alle Nutzer des Geräts. Lassen Sie die Nutzerangabe nicht unbedacht weg.

Erwartetes Ergebnis: Das Ersatz-APK wird für den ausgewählten Nutzer als Neuinstallation behandelt und nicht als Aktualisierung der widersprüchlichen Installation.

Risiko und Wiederherstellung: Das Risiko ist hoch. Eine erneute Installation kann die App-Dateien wiederherstellen, aber keine gelöschten lokalen Daten zurückholen, sofern keine separate und nutzbare Sicherung vorhanden ist.

Was diesen Fehler nicht behebt und wie sich andere Installationsfehler abgrenzen lassen

  • versionCode erhöhen: Dies ist erforderlich, wenn die normalen Aktualisierungsregeln es verlangen, kann aber kein APK autorisieren, das mit einem anderen Zertifikat signiert wurde.
  • Gradle-Caches leeren: Dadurch ändert sich die Signaturidentität des APKs nicht.
  • Bereinigen und neu erstellen, ohne die Signatur zu korrigieren: Ein Neubau hilft nur, wenn dadurch die autorisierte Signaturkonfiguration wiederhergestellt wird.
  • App-Speicher leeren oder sichtbare Dateien löschen: Dadurch ändert sich die autorisierte Signaturidentität des Pakets nicht.
  • Nur den Play-Upload-Schlüssel vergleichen: Das von Google Play verteilte APK kann ein anderes App-Signaturzertifikat verwenden.
Fehler Entscheidender Unterschied
INSTALL_FAILED_UPDATE_INCOMPATIBLE Zwischen dem vorhandenen Paket und dem eingehenden APK besteht keine autorisierte Signaturbeziehung.
INSTALL_FAILED_VERSION_DOWNGRADE Die eingehende Version ist niedriger. Dies ist nicht der hier behandelte Zertifikatskonflikt.
INSTALL_FAILED_INVALID_APK Das Installationsprogramm stuft das APK als ungültig ein und nicht als nicht autorisierte signierte Aktualisierung.
INSTALL_FAILED_INSUFFICIENT_STORAGE Für die Installation steht nicht genügend Speicherplatz zur Verfügung; es fehlt nicht an einer kompatiblen Signaturidentität.

Die Behebung ist bestätigt, wenn das vorgesehene Ziel das APK als autorisierte Aktualisierung akzeptiert oder wenn eine bewusst entfernte, entbehrliche Installation das APK als Neuinstallation annimmt. Wenn die Installation erfolgreich ist, die Anwendung später jedoch eine davon unabhängige Laufzeitausnahme bei der Dateifreigabe meldet, lesen Sie stattdessen android.os.FileUriExposedException unter Android beheben.