Что происходит, когда Android-приложение меняет название, но не package name?

Переменить имя приложения для пользователя проще простого — но под капотом Android устроена система идентификаторов, где путаница может привести к дублированию приложений и потере обновлений.

Бренд-название — это то, что узнают люди. Package name — то, что узнает Android. И менять их нужно по отдельным правилам.

Переименовать Android-приложение кажется пустяком: обновил название в strings.xml, поменял иконку, залил новую версию — и готово. Но на практике у каждого приложения сразу несколько «личностей», и смешивать их — прямой путь к проблемам для пользователей.

Разберёмся, как устроена система идентификации Android-приложений и что нужно знать разработчику (или просто любопытному пользователю), когда приложение проходит через ребрендинг.

Два имени одного приложения

У любого Android-приложения есть видимое имя — то, что отображается на иконке в лаунчере, в настройках и в магазине приложений. Именно его видит пользователь. В проекте оно хранится в файле strings.xml и меняется одной строкой.

Но для операционной системы это имя — чистая косметика. Android определяет приложение по application ID (он же package name) — уникальному идентификатору вроде com.example.originalapp. Именно по нему система понимает, что перед ней одно и то же приложение, даже если пользователь видит совершенно другое название.

Получается, разработчик может спокойно переименовать приложение из «Original App» в «New App», оставив package name com.example.originalapp без изменений. Технически это абсолютно корректная операция.

Зачем сохранять старый package name

Вопрос не праздный. Если приложение уже опубликовано и у него есть пользователи, смена application ID превращает обновление в совершенно новое приложение. Android увидит два отдельных пакета: на устройстве одновременно окажутся «Original App» и «New App» — со всеми вытекающими.

Пользователи потеряют обновления, данные старого приложения не перенесутся автоматически, подписки и покупки внутри приложения окажутся привязаны к старому идентификатору. Для коммерческого продукта это катастрофа.

Поэтому стандартная практика: имя для людей меняется, идентификатор для системы — нет.

Подпись: забытый третий фактор

Package name — не единственное условие корректного обновления. Android требует, чтобы новая версия APK была подписана тем же сертификатом, что и предыдущая. Если сертификат изменится, система отклонит обновление — даже при совпадении application ID.

Именно поэтому ключи подписи приложений нужно хранить с особым вниманием. Потеря закрытого ключа означает невозможность выпустить обновление для существующей аудитории. Это одна из причин, по которой Google ввёл систему управления ключами подписи на уровне Google Play.

В схеме всё выглядит так: версия 1 с package com.example.app, подписанная сертификатом A, обновляется до версии 2 с тем же package и тем же сертификатом. Если хотя бы один элемент меняется — цепочка обновлений рвётся.

Версионирование при ребрендинге

Ещё один нюанс — коды версий. При ребрендинге versionCode должен продолжать существующую нумерацию. Если до смены бренда последней версией был versionCode: 23, то первая версия с новым именем должна быть 24, а не 1.

Это может показаться неочевидным: ведь для пользователя начинается «новое» приложение. Но для системы это продолжение того же приложения, и понижение version code просто не позволит установить обновление поверх существующей версии.

Публичное имя бренда и техническая идентификация — два параллельных слоя, которые живут по своим правилам.

Магазины приложений: когда обновления не синхронизируются

Если приложение распространяется через альтернативные маркетплейсы вроде Uptodown, Amazon Appstore или отечественные магазины, ситуация усложняется. Страница приложения вмагазине содержит десятки метаданных: название, описание, скриншоты, имя разработчика, URL-адрес, историю версий.

При ребрендинге эти данные обновляются не одновременно. Некоторые поля подтягиваются из нового APK сразу, другие — вручную или по расписанию краулером. В результате пользователь может увидеть страницу, где название уже новое, а скриншоты и описание — от старого бренда. Или наоборот: URL ведёт на старое имя, а контент уже обновлён.

Это нормальное (хоть и неудобное) явление. Ссылки часто сохраняют в прежнем виде, чтобы не ломать существующие внешние ссылки и закладки. Поэтому URL original-app.example.com может оставаться актуальным даже после того, как приложение давно называется иначе.

Что именно нужно менять при ребрендинге

Полноценный ребрендинг Android-приложения затрагивает не только одну строку в конфигурации. Вот что обычно обновляется:

• видимое имя приложения;
• иконка в лаунчере;
• заставка (splash screen);
• скриншоты в магазине;
• описание приложения;
• внутренний брендинг в интерфейсе;
• имя и иконка в уведомлениях;
• deep links и поддерживаемые URI;
• ссылки на сайт и страницы поддержки;
• метаданные в магазинах приложений.

При этом технические идентификаторы менять следует только при наличии веской причины — например, если приложение действительно должно существовать как отдельный продукт.

Чего нельзя допускать

Ребрендинг — источник типичных ошибок. Самая грубая — случайная смена application ID, которая превращает обновление в дубликат.

Также перед публикацией стоит проверить:

• используется ли правильный сертификат подписи;
• увеличен ли versionCode;
• удалены ли элементы старого бренда из ключевых экранов;
• работают ли ссылки и страницы поддержки;
• отображается ли корректная информация на страницах в магазинах.

Особенно важно протестировать путь обновления: установить предыдущую версию на устройство, затем обновить её до ребрендинговой сборки и убедиться, что Android принял обновление, данные сохранились, а новое имя и иконка отображаются корректно.

Суть

Ребрендинг Android-приложения — не косметическая операция. Это работа на стыке пользовательского восприятия и технической идентификации. Система Android жёстко разделяет то, что видит человек, и то, что читает операционная система. Нарушить эту границу — значит заставить пользователей скачивать «новое» приложение, терять данные и наживать проблемы с подписками.

Правильный подход прост: меняйте всё, что относится к бренду, и ничего — что относится к идентификатору приложения, если только вы сознательно не хотите создать отдельный продукт.