INSTALL_FAILED_UPDATE_INCOMPATIBLE, junto con el mensaje proporcionado sobre firmas no coincidentes Package <package_name> signatures do not match the previously installed version; ignoring!, significa que Android rechazó el APK entrante porque no está autorizado para actualizar un paquete existente. Esto puede ocurrir al implementar un APK mediante Android Studio, ADB, dispositivos físicos, emuladores y otros instaladores de paquetes. La medida inicial más segura es conservar intacta la instalación existente mientras verificas el dispositivo de destino, el paquete, el usuario de Android y el certificado de firma del APK entrante.

Qué significa INSTALL_FAILED_UPDATE_INCOMPATIBLE

Android identifica una actualización mediante el ID de aplicación, también llamado nombre del paquete, y su identidad de firma autorizada. Un APK solo puede actualizar la aplicación existente cuando coincide el ID de aplicación y también coincide el certificado de firma de la app instalada, o cuando una prueba de rotación válida establece un historial de firma autorizado. Este requisito se documenta en los requisitos de Android para actualizar apps.

El texto exacto del instalador puede variar según el instalador y la compilación de Android. La documentación oficial de Android establece la regla relativa al certificado, pero no publica un mensaje universal para todas las compilaciones.

Entre los contextos habituales confirmados se encuentran un APK de depuración que intenta reemplazar una compilación de lanzamiento, un APK local que intenta reemplazar una compilación distribuida mediante Google Play, una instalación anterior en el emulador o dispositivo seleccionado, o un estado del paquete perteneciente a otro usuario de Android o perfil de trabajo. Para una actualización normal también se requiere un código de versión válido, pero este no puede autorizar un certificado de firma diferente.

Verifica el dispositivo de destino, el paquete y el usuario de Android

Hazlo antes de cambiar la configuración de firma o eliminar cualquier elemento. Sustituye SERIAL, USER_ID y PACKAGE_NAME únicamente por valores que hayas verificado.

  1. Ejecuta adb devices -l.
  2. Identifica el dispositivo físico o emulador previsto y anota su número de serie.
  3. Confirma el ID de aplicación exacto o el nombre del paquete de la app.
  4. Consulta ese paquete para el usuario correspondiente con adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.

Es importante limitar los comandos por número de serie cuando hay varios dispositivos o emuladores conectados. La documentación oficial de ADB describe la selección del destino y las operaciones del administrador de paquetes utilizadas aquí.

Resultado esperado: la consulta identifica el estado existente del paquete para ese usuario o no devuelve ningún paquete coincidente. Un resultado vacío para el usuario principal no demuestra que todos los usuarios secundarios o perfiles administrados estén libres de ese paquete; comprueba esos contextos por separado antes de desinstalar nada.

Riesgo y reversión: estos comandos inspeccionan los destinos y el estado del paquete sin eliminar intencionalmente la app. Si no tienes certeza sobre el número de serie, el nombre del paquete o el usuario, detente en lugar de ejecutar un comando destructivo.

Inspecciona el certificado de firma del APK entrante

Inspecciona el APK que realmente intentas implementar:

  1. Ejecuta apksigner verify --print-certs app.apk.
  2. Cuando tengas acceso, compara el certificado mostrado con la configuración de firma autorizada conocida de la app.
  3. Si los certificados son diferentes y no se aplica un linaje de firma válido, detén el intento de actualización.

La identidad pertinente puede ser un certificado de depuración, un certificado de lanzamiento administrado localmente o el certificado de firma de la app utilizado para una compilación distribuida mediante Play. Un certificado de carga no es necesariamente el certificado utilizado para firmar los APK que entrega Google Play. La documentación de Android sobre la firma de apps explica cómo comparar certificados y la diferencia entre la clave de firma de la app y la clave de carga.

Android 9 y versiones posteriores admiten la prueba de rotación del esquema de firma de APK v3. Un linaje de rotación válido puede autorizar un certificado más reciente, pero generar o seleccionar una clave diferente no basta. El acceso a un APK instalado o a su certificado también puede estar restringido, por lo que quizá sea necesario confirmar la identidad instalada mediante registros de lanzamiento conocidos en lugar de deducirla.

Resultado esperado: determinas si el APK entrante utiliza la identidad autorizada de firma de la app o un linaje válido. La inspección del certificado no modifica la app instalada.

Conserva los datos de la app volviendo a compilar con la identidad de firma autorizada

Cuándo corresponde: utiliza esta opción preferente cuando deban conservarse la instalación existente y sus datos locales, el ID de aplicación no haya cambiado y controles la clave correcta de firma de la app o un proceso de rotación válido. El versionCode entrante no debe ser inferior al de la versión instalada.

Requisitos previos:

  • Se verificaron el número de serie, el usuario y el nombre del paquete previstos.
  • Tienes acceso a la configuración establecida de firma de la app o a una prueba de rotación válida.
  • No eliminaste la instalación existente.
  1. Ejecuta adb devices -l y selecciona el número de serie previsto.
  2. Ejecuta adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  3. Inspecciona el APK entrante con apksigner verify --print-certs app.apk.
  4. Compila el APK con la configuración establecida de firma de la app.
  5. Instálalo en el destino seleccionado con adb -s SERIAL install -r app.apk.
  6. Si los certificados son diferentes, detente. No esperes que cambiar el código de versión, borrar la caché o hacer una compilación limpia autorice la actualización.

Resultado esperado: Android acepta el APK como una actualización autorizada si su ID de aplicación, los requisitos de versión y la identidad de firma o el linaje válido satisfacen las comprobaciones de actualización. Esto no puede garantizarse sin verificar el estado del paquete en el dispositivo específico.

Riesgo y reversión: el riesgo es bajo porque se conserva el paquete existente. Si la instalación sigue siendo rechazada, mantén la instalación actual y vuelve a compilar con la configuración de firma autorizada en lugar de sustituirla por una clave privada nueva.

Gestiona una app instalada desde Google Play

Cuándo corresponde: utiliza esta opción cuando la copia instalada proceda de Google Play y el APK local esté firmado con una clave de carga u otra clave local.

Requisitos previos: la Firma de apps de Play está habilitada y tienes acceso a un segmento de prueba aprobado, al Uso compartido interno de apps o a artefactos de lanzamiento generados por Play.

  1. Confirma si la Firma de apps de Play administra la clave de firma de la app distribuida.
  2. No compares la app instalada únicamente con el certificado de la clave de carga; la clave de carga y la clave de firma de la app distribuida pueden ser diferentes.
  3. Utiliza el Uso compartido interno de apps para probar lo que entrega Google Play o descarga los artefactos APK generados por Play.
  4. Para los APK divididos descargados localmente, utiliza adb install-multiple como se documenta.
  5. Utiliza un APK firmado localmente solo si tiene la misma identidad autorizada de firma de la app.

En las actualizaciones de la clave de firma de Play, Android 13 y versiones posteriores pueden recibir APK firmados con la clave actualizada, mientras que las versiones anteriores de Android reciben actualizaciones firmadas con la clave antigua.

Resultado esperado: el artefacto de prueba se distribuye con una identidad de firma compatible con la versión instalada desde Play. Que coincida únicamente la clave de carga no demuestra compatibilidad.

Riesgo y reversión: el riesgo es bajo cuando la app instalada desde Play permanece en el dispositivo. Consérvala y vuelve al método de prueba apropiado de Play si el artefacto local no puede autorizarse.

Comprueba usuarios secundarios, perfiles de trabajo y dispositivos administrados

Cuándo corresponde: utiliza esta ruta de diagnóstico cuando la app parezca ausente en el perfil principal o el dispositivo tenga usuarios secundarios, un perfil de trabajo, un perfil administrado o un aislamiento de paquetes similar al de Carpeta Segura.

Requisitos previos: acceso de depuración por USB o inalámbrico y permiso para inspeccionar el dispositivo. Las políticas empresariales pueden limitar la visibilidad y las operaciones con paquetes.

  1. Selecciona el destino previsto con adb -s SERIAL.
  2. Enumera sus usuarios con adb -s SERIAL shell pm list users.
  3. Para cada ID pertinente, ejecuta adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  4. Utiliza explícitamente el ID de usuario verificado en los comandos posteriores del administrador de paquetes.
  5. Si un perfil empresarial controla el paquete, utiliza el procedimiento de administración aprobado por la organización.
  6. No intentes eludir las restricciones de las políticas del dispositivo.

Resultado esperado: identificas si el estado conflictivo del paquete pertenece a otro usuario o perfil. El aislamiento de perfiles puede hacer que una app no sea visible desde el perfil principal, pero esta es una posibilidad que debe verificarse, no una causa que deba darse por sentada.

Riesgo y reversión: la inspección no es destructiva, pero la propiedad y la visibilidad de los perfiles varían. Detente si la política o la propiedad no están claras; los comandos de inspección indicados no requieren reversión.

Elimina una instalación de prueba conflictiva solo si sus datos son prescindibles

Advertencia sobre pérdida de datos: desinstalar puede eliminar los datos locales de la app. Reinstalar recupera los archivos binarios de la app, pero no los datos eliminados. Continúa únicamente si se trata de una instalación de prueba prescindible o si aceptaste expresamente la pérdida y verificaste cualquier copia de seguridad independiente que necesites.

Cuándo corresponde: utiliza esta alternativa destructiva solo cuando no sea necesario conservar la instalación existente o no esté disponible la identidad de firma autorizada correcta y resulte aceptable hacer una instalación nueva.

Requisitos previos:

  • Se verificaron el número de serie, el nombre del paquete y el ámbito del usuario.
  • Los datos de prueba necesarios se exportaron a una ubicación independiente o se sabe que son prescindibles.
  • El paquete no está sujeto a una eliminación no autorizada de un perfil administrado.
  1. Confirma el destino con adb devices -l.
  2. Confirma el paquete y el usuario con adb -s SERIAL shell pm list packages --user USER_ID PACKAGE_NAME.
  3. Para un solo usuario, ejecuta adb -s SERIAL shell pm uninstall --user USER_ID PACKAGE_NAME.
  4. Instala el APK de reemplazo después de eliminar el paquete.
  5. Vuelve a crear o restaura únicamente los datos disponibles en una copia de seguridad independiente y utilizable.

Advertencia: sin --user, pm uninstall elimina de forma predeterminada el paquete para todos los usuarios del dispositivo. No omitas el ámbito del usuario sin evaluar las consecuencias.

Resultado esperado: el reemplazo se trata como una instalación nueva para el usuario seleccionado, no como una actualización de la instalación conflictiva.

Riesgo y reversión: el riesgo es alto. La reinstalación puede recuperar los archivos binarios, pero no los datos locales eliminados, salvo que exista una copia de seguridad independiente y utilizable.

Qué no corrige este error y cómo descartar otros fallos de instalación

  • Incrementar versionCode: es necesario cuando lo exigen las reglas normales de actualización, pero no puede autorizar un APK firmado con un certificado diferente.
  • Borrar las cachés de Gradle: esto no cambia la identidad de firma del APK.
  • Limpiar y volver a compilar sin corregir la firma: volver a compilar solo ayuda si restaura la configuración de firma autorizada.
  • Borrar el almacenamiento de la app o eliminar archivos visibles: esto no cambia la identidad de firma autorizada del paquete.
  • Comparar únicamente la clave de carga de Play: el APK distribuido mediante Play puede utilizar un certificado diferente de firma de la app.
Error Diferencia específica
INSTALL_FAILED_UPDATE_INCOMPATIBLE El paquete existente y el APK entrante no tienen una relación de firma autorizada.
INSTALL_FAILED_VERSION_DOWNGRADE La versión entrante es inferior; no es el conflicto de certificados tratado aquí.
INSTALL_FAILED_INVALID_APK El instalador considera que el APK no es válido, en lugar de tratarlo como una actualización firmada no autorizada.
INSTALL_FAILED_INSUFFICIENT_STORAGE No hay suficiente almacenamiento disponible para la instalación; no se trata de una identidad de firma incompatible.

La resolución queda verificada cuando el destino previsto acepta el APK como una actualización autorizada o cuando una instalación prescindible, eliminada de forma deliberada, lo acepta como una instalación nueva. Si la instalación se completa, pero posteriormente la app informa de una excepción de ejecución no relacionada al compartir archivos, consulta cómo corregir android.os.FileUriExposedException en Android.