При обновлении Android сообщает о конфликте с уже установленным приложением. Как доказать, что причина — несовместимая подпись новой сборки?
Нужно сравнить сертификат подписи установленной и новой сборок, прежде всего их отпечатки и цепочку доверия. Если идентификатор пакета совпадает, но новая сборка подписана другим несовместимым ключом, Android рассматривает её не как обновление существующего приложения, а как попытку заменить его чужим пакетом.
Подтверждение получают воспроизведением обновления поверх старой версии, сравнением сертификатов и контрольной установкой новой сборки после удаления старой. Если после удаления установка проходит, а обновление поверх старой версии — нет, это сильный признак проблемы совместимости подписи, но дополнительно нужно исключить несовместимый идентификатор пакета и некорректный номер версии.
Модель подписанных приложений появилась для подтверждения происхождения обновлений и защиты данных уже установленного приложения. Операционная система должна отличать легитимное обновление от пакета, который пытается занять тот же идентификатор и получить доступ к прежнему хранилищу.
Поэтому обновление обычно допускается только при сохранении непрерывности идентичности приложения: совпадает идентификатор пакета, а новая подпись совместима с подписью установленной версии. В некоторых каналах распространения поддерживается контролируемая ротация ключей, но она не означает, что любая новая подпись автоматически совместима со старой.
Ошибка проявляется после установки старой версии из одного источника и попытки установить новую сборку из другого. Пользователь может увидеть сообщение о конфликте пакета, отказ установки или требование удалить приложение.
Неверная диагностика опасна: удаление приложения как временное решение может стереть локальные данные, а публикация новой сборки с неправильным ключом заблокирует обычное обновление для всех пользователей старой версии. При этом похожий симптом могут вызывать другой идентификатор пакета, пониженный номер версии, неподдерживаемая версия Android или ограничения конкретного канала доставки.
Сначала устанавливают исходную версию обычным способом, не очищая её данные. Затем пытаются установить новую сборку поверх неё и фиксируют точное сообщение системы и код результата, если канал распространения его предоставляет.
После этого сравнивают у старой и новой сборок:
Ключевой эксперимент — установить новую сборку на чистое устройство или после удаления старой. Если чистая установка успешна, а обновление поверх старой не выполняется, нужно сопоставить сертификаты. Разные сертификаты без совместимой цепочки ротации подтверждают версию с конфликтом подписи.
Нельзя делать вывод только по названию приложения: отображаемое имя может быть одинаковым у разных пакетов. Также недостаточно проверить, что сборка подписана: важно, что её подписант совместим именно с подписантом установленной версии.
В релизном процессе следует проверять обновление с нескольких предыдущих публичных версий, особенно после смены хранилища ключей, сборочного конвейера или канала публикации. Если ключ действительно нужно заменить, используют предусмотренный каналом распространения механизм ротации и заранее проверяют его совместимость; простая подпись новым ключом не является безопасной заменой.
Тестировщик получил жалобу: версия из магазина уже установлена, а внутренняя тестовая сборка с тем же названием не устанавливается. Рассматривались три варианта: удалить старую версию, изменить идентификатор пакета или проверить подписи.
Удаление быстро подтверждало, что новая сборка вообще запускается, но не объясняло причину и уничтожало локальные данные. Изменение идентификатора позволяло установить сборку рядом с магазинной, однако превращало её в другое приложение и не проверяло сценарий обновления. Поэтому выбрали сравнение идентификаторов, номеров версий и сертификатов с последующей установкой поверх сохранённой старой версии.
Идентификаторы и версия были корректными, но отпечатки сертификатов отличались. После сборки тестового варианта тем же ключом обновление прошло, а данные приложения сохранились. Значит, дефект находился в конфигурации подписи тестового конвейера, а не в хранилище или логике запуска приложения.
Нет. Идентификатор сообщает системе, какое приложение предполагается обновить, но не подтверждает, что новая сборка выпущена тем же доверенным владельцем. При несовместимой подписи Android должен отклонить замену, иначе любой пакет с известным идентификатором мог бы претендовать на данные установленного приложения.
Удаление убирает прежнюю запись о подписанте и локальные данные приложения. Новая сборка проверяется уже как самостоятельная установка, поэтому конфликт со старым сертификатом не возникает. Такой эксперимент локализует проблему к сценарию обновления, но не показывает, сохранится ли пользовательское состояние и допустима ли новая подпись для существующей аудитории.
Да, в поддерживаемых сценариях распространения возможна управляемая ротация ключей с механизмом, подтверждающим преемственность. Но совместимость зависит от версии Android, формата подписи и канала доставки, поэтому её нельзя предполагать по одному факту смены сертификата. Тестировщик должен проверить обновление на целевых версиях ОС и подтвердить, что новая подпись признана преемственной, а не просто отличается от старой.