INSTALL_FAILED_UPDATE_INCOMPATIBLE, accompagné ici du message de non-correspondance des signatures Package <package_name> signatures do not match the previously installed version; ignoring!, signifie qu’Android a refusé l’APK entrant, car il ne constitue pas une mise à jour autorisée d’un package existant. Cette erreur peut survenir lors du déploiement d’un APK avec Android Studio ou ADB, sur un appareil physique, un émulateur ou au moyen d’un autre programme d’installation de packages. La première mesure, et la plus sûre, consiste à conserver l’installation existante pendant que vous vérifiez l’appareil cible, le package, l’utilisateur Android et le certificat de signature de l’APK entrant.

Que signifie INSTALL_FAILED_UPDATE_INCOMPATIBLE ?

Android identifie une mise à jour à l’aide de l’ID d’application, également appelé nom du package, et de l’identité de signature autorisée. Un APK ne peut mettre à jour l’application existante que si l’ID d’application correspond et si le certificat de signature est identique à celui de l’application installée, ou si une preuve de rotation valide établit un historique de signature autorisé. Cette exigence est décrite dans la documentation sur le fonctionnement des mises à jour d’applications Android.

Le libellé exact affiché peut varier selon le programme d’installation et la version d’Android. La documentation officielle d’Android établit la règle relative aux certificats, mais ne publie pas un message d’installation universel pour toutes les versions. Le message anglais ci-dessus est donc conservé tel qu’il apparaît à l’écran.

Les situations courantes confirmées comprennent notamment un APK de débogage qui tente de remplacer une version publiée, un APK local qui tente de remplacer une version distribuée par Google Play, une installation antérieure sur l’émulateur ou l’appareil sélectionné, ou encore un état de package appartenant à un autre utilisateur Android ou à un profil professionnel. Un code de version valide reste nécessaire pour une mise à jour normale, mais il ne peut pas autoriser un certificat de signature différent.

Vérifier l’appareil cible, le package et l’utilisateur Android

Effectuez ces contrôles avant de modifier les paramètres de signature ou de supprimer quoi que ce soit. Remplacez SERIAL, USER_ID et PACKAGE_NAME uniquement par des valeurs que vous avez vérifiées.

  1. Exécutez adb devices -l.
  2. Identifiez l’appareil physique ou l’émulateur prévu, puis notez son numéro de série.
  3. Confirmez l’ID d’application exact, ou nom du package, de l’application.
  4. Recherchez ce package pour l’utilisateur concerné avec adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.

Il est important de préciser le numéro de série dans les commandes lorsque plusieurs appareils ou émulateurs sont connectés. La documentation officielle d’ADB décrit la sélection de la cible et les opérations du gestionnaire de packages utilisées ici.

Résultat attendu : la requête détecte un état existant du package pour cet utilisateur ou ne renvoie aucun package correspondant. Un résultat vide pour l’utilisateur principal ne prouve pas que tous les utilisateurs secondaires ou profils gérés sont exempts de ce package. Vérifiez séparément ces contextes avant toute désinstallation.

Risque et retour en arrière : ces commandes examinent les cibles et l’état des packages sans supprimer volontairement l’application. Si le numéro de série, le nom du package ou l’utilisateur est incertain, arrêtez-vous au lieu d’exécuter une commande destructive.

Examiner le certificat de signature de l’APK entrant

Examinez l’APK que vous essayez réellement de déployer :

  1. Exécutez apksigner verify --print-certs app.apk.
  2. Comparez le certificat affiché avec la configuration de signature autorisée connue de l’application, si vous y avez accès.
  3. Si les certificats diffèrent et qu’aucune lignée de signature valide ne s’applique, interrompez la tentative de mise à jour.

L’identité concernée peut être un certificat de débogage, un certificat de publication géré localement ou le certificat de signature d’application utilisé pour une version distribuée par Google Play. Un certificat de clé d’importation n’est pas nécessairement celui utilisé pour signer les APK fournis par Google Play. La documentation Android sur la signature des applications explique la comparaison des certificats et la distinction entre la clé de signature d’application et la clé d’importation.

Android 9 et les versions ultérieures prennent en charge la preuve de rotation du schéma de signature APK v3. Une lignée de rotation valide peut autoriser un certificat plus récent, mais la simple génération ou sélection d’une autre clé ne suffit pas. L’accès à un APK installé ou à son certificat peut également être restreint. Il peut donc être nécessaire de confirmer l’identité installée à partir des enregistrements de publication connus, plutôt que de la déduire.

Résultat attendu : vous déterminez si l’APK entrant utilise l’identité de signature d’application autorisée ou une lignée valide. L’examen du certificat ne modifie pas l’application installée.

Préserver les données de l’application en reconstruisant l’APK avec l’identité de signature autorisée

Quand utiliser cette méthode : privilégiez cette solution lorsque l’installation existante et les données locales doivent être conservées, que l’ID d’application reste inchangé et que vous contrôlez la bonne clé de signature d’application ou un processus de rotation valide. Le versionCode de l’APK entrant ne doit pas être inférieur à celui de la version installée.

Conditions préalables :

  • Le numéro de série, l’utilisateur et le nom du package prévus ont été vérifiés.
  • Vous avez accès à la configuration de signature d’application établie ou à une preuve de rotation valide.
  • Vous n’avez pas supprimé l’installation existante.
  1. Exécutez adb devices -l et sélectionnez le numéro de série prévu.
  2. Exécutez adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  3. Examinez l’APK entrant avec apksigner verify --print-certs app.apk.
  4. Générez l’APK avec la configuration de signature d’application établie.
  5. Installez-le sur la cible sélectionnée avec adb -s SERIAL install -r app.apk.
  6. Si les certificats diffèrent, arrêtez-vous. Une modification du code de version, la suppression du cache ou une reconstruction propre n’autorisera pas la mise à jour.

Résultat attendu : Android accepte l’APK comme mise à jour autorisée si son ID d’application, les exigences de version et son identité de signature ou sa lignée valide satisfont les contrôles de mise à jour. Ce résultat ne peut pas être garanti sans vérifier l’état du package sur l’appareil concerné.

Risque et retour en arrière : le risque est faible, car le package existant est conservé. Si l’installation est toujours refusée, conservez l’installation actuelle et reconstruisez l’APK avec la configuration de signature autorisée, au lieu de lui substituer une nouvelle clé privée.

Traiter le cas d’une application installée depuis Google Play

Quand utiliser cette méthode : suivez cette procédure lorsque la version installée provient de Google Play et que votre APK local est signé avec une clé d’importation ou une autre clé locale.

Conditions préalables : la signature d’application Play est activée, et vous avez accès à un canal de test approuvé, au partage interne d’applications ou aux artefacts de publication générés par Play.

  1. Vérifiez si la signature d’application Play gère la clé de signature de l’application distribuée.
  2. Ne comparez pas l’application installée uniquement au certificat de la clé d’importation : la clé d’importation et la clé de signature de l’application distribuée peuvent être différentes.
  3. Utilisez le partage interne d’applications pour tester ce que Google Play distribue, ou téléchargez des artefacts APK générés par Play.
  4. Pour des APK fractionnés téléchargés localement, utilisez adb install-multiple conformément à la documentation.
  5. N’utilisez un APK signé localement que s’il possède la même identité de signature d’application autorisée.

Lors d’une mise à niveau de la clé de signature Play, Android 13 et les versions ultérieures peuvent recevoir des APK signés avec la nouvelle clé, tandis que les versions antérieures d’Android reçoivent des mises à jour signées avec l’ancienne clé.

Résultat attendu : l’artefact de test est distribué avec une identité de signature compatible avec la version installée depuis Google Play. La seule correspondance avec la clé d’importation ne constitue pas une preuve de compatibilité.

Risque et retour en arrière : le risque est faible tant que l’application installée depuis Google Play reste en place. Conservez-la et revenez au canal de test Play approprié si l’artefact local ne peut pas être autorisé.

Vérifier les utilisateurs secondaires, les profils professionnels et les appareils gérés

Quand utiliser cette méthode : suivez cette procédure de diagnostic si l’application semble absente du profil principal ou si l’appareil comporte des utilisateurs secondaires, un profil professionnel, un profil géré ou un cloisonnement de packages de type « Dossier sécurisé ».

Conditions préalables : vous devez disposer d’un accès au débogage USB ou sans fil et de l’autorisation d’examiner l’appareil. Les règles de l’entreprise peuvent limiter la visibilité et les opérations sur les packages.

  1. Sélectionnez la cible prévue avec adb -s SERIAL.
  2. Répertoriez ses utilisateurs avec adb -s SERIAL shell pm list users.
  3. Pour chaque identifiant concerné, exécutez adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  4. Utilisez explicitement l’identifiant utilisateur vérifié dans les commandes ultérieures du gestionnaire de packages.
  5. Si un profil d’entreprise contrôle le package, suivez la procédure d’administration approuvée par l’organisation.
  6. N’essayez pas de contourner les restrictions imposées par la stratégie de l’appareil.

Résultat attendu : vous déterminez si l’état de package conflictuel appartient à un autre utilisateur ou profil. Le cloisonnement des profils peut rendre une application invisible depuis le profil principal, mais cette possibilité doit être vérifiée et ne doit pas être considérée d’emblée comme la cause.

Risque et retour en arrière : l’examen n’est pas destructif, mais la propriété et la visibilité des profils varient. Arrêtez-vous si la stratégie ou la propriété n’est pas claire. Aucun retour en arrière n’est nécessaire pour les commandes d’examen indiquées.

Supprimer une installation de test conflictuelle uniquement si ses données sont inutiles

Avertissement concernant la perte de données : la désinstallation peut supprimer les données locales de l’application. La réinstallation restaure le programme, mais pas les données supprimées. Ne continuez que pour une installation de test sans données importantes, ou après avoir expressément accepté leur perte et vérifié toute sauvegarde indépendante dont vous avez besoin.

Quand utiliser cette méthode : n’utilisez cette solution destructive qu’en dernier recours, lorsque la conservation de l’installation existante n’est pas nécessaire ou que l’identité de signature autorisée est indisponible et qu’une nouvelle installation est acceptable.

Conditions préalables :

  • Le numéro de série, le nom du package et le périmètre utilisateur ont été vérifiés.
  • Les données de test nécessaires ont été exportées vers un emplacement indépendant ou sont reconnues comme inutiles.
  • Le package ne doit pas être supprimé d’un profil géré sans autorisation.
  1. Confirmez la cible avec adb devices -l.
  2. Confirmez le package et l’utilisateur avec adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  3. Pour un seul utilisateur, exécutez adb -s SERIAL shell pm uninstall --user USER_ID PACKAGE_NAME.
  4. Installez l’APK de remplacement après la suppression.
  5. Ne recréez ou ne restaurez que les données disponibles dans une sauvegarde indépendante et exploitable.

Avertissement : sans --user, pm uninstall supprime par défaut le package pour tous les utilisateurs de l’appareil. N’omettez pas le périmètre utilisateur sans en mesurer les conséquences.

Résultat attendu : le remplacement est traité comme une nouvelle installation pour l’utilisateur sélectionné, et non comme une mise à jour de l’installation conflictuelle.

Risque et retour en arrière : le risque est élevé. La réinstallation peut restaurer le programme, mais elle ne peut pas récupérer les données locales supprimées, sauf si une sauvegarde distincte existe et peut être utilisée.

Ce qui ne corrigera pas cette erreur et comment écarter les autres échecs d’installation

  • Augmenter le versionCode : cette opération est nécessaire lorsque les règles normales de mise à jour l’exigent, mais elle ne peut pas autoriser un APK signé avec un autre certificat.
  • Vider les caches Gradle : cela ne change pas l’identité de signature de l’APK.
  • Nettoyer et reconstruire sans corriger la signature : la reconstruction n’est utile que si elle rétablit la configuration de signature autorisée.
  • Effacer l’espace de stockage de l’application ou supprimer les fichiers visibles : cela ne modifie pas l’identité de signature autorisée du package.
  • Comparer uniquement la clé d’importation Play : l’APK distribué par Play peut utiliser un autre certificat de signature d’application.
Erreur Distinction précise
INSTALL_FAILED_UPDATE_INCOMPATIBLE Le package existant et l’APK entrant ne possèdent pas de relation de signature autorisée.
INSTALL_FAILED_VERSION_DOWNGRADE La version entrante est inférieure ; il ne s’agit pas du conflit de certificats traité ici.
INSTALL_FAILED_INVALID_APK Le programme d’installation considère l’APK comme non valide, plutôt que comme une mise à jour signée non autorisée.
INSTALL_FAILED_INSUFFICIENT_STORAGE L’espace de stockage disponible est insuffisant ; le problème ne concerne pas une identité de signature compatible.

La résolution est confirmée lorsque la cible prévue accepte l’APK comme mise à jour autorisée, ou lorsqu’une installation sans données importantes, supprimée volontairement, accepte l’APK comme nouvelle installation. Si l’installation réussit, mais que l’application signale ensuite une exception d’exécution distincte liée au partage de fichiers, consultez plutôt comment corriger android.os.FileUriExposedException sur Android.