При разработке и публикации автономных мобильных приложений на платформе 1С часто возникает вопрос: что происходит с накопленными данными пользователей при выходе новой версии конфигурации и установке обновленного APK-пакета из магазина приложений или корпоративного источника? Разберем подробно внутреннюю механику обновления, правила сборки мобильного пакета и порядок обработки изменений метаданных.
Механизм обновления приложения в операционной системе Android
Когда пользователь устанавливает новую версию приложения поверх предыдущей, операционная система Android не удаляет программу полностью, а выполняет процедуру обновления. Выясним, как при этом распределяются файлы приложения и база данных:
Системные файлы и ресурсы: Бинарные библиотеки платформы, ассеты и новый файл конфигурации поставки заменяют старые файлы пакета.
Локальная база данных: Каталог с пользовательскими данными и встроенная база данных (файловая база мобильной платформы) сохраняются во внутреннем изолированном хранилище приложения без изменений.
Таким образом, при стандартном обновлении APK-файла пользовательские данные не затираются и не удаляются операционной системой.
Обязательные технические требования при сборке новой версии APK
Для того чтобы ОС Android и магазин приложений (Google Play, RuStore и др.) распознали пакет именно как обновление, а не как отдельное приложение или несовместимый файл, необходимо соблюдать ключевые правила сборки:
Идентичный ключ подписи (Keystore): Новый APK-пакет или Android App Bundle (AAB) должен быть подписан ровно тем же цифровым сертификатом (Release Keystore), что и предыдущая версия. Если ключ подписи утерян или изменен, операционная система заблокирует установку поверх старой версии. В таком случае единственным вариантом станет полное удаление приложения с устройства, что приведет к безвозвратной утрате всей локальной базы данных.
Совпадение идентификатора приложения (Package Name): Имя пакета должно оставаться строго неизменным на протяжении всего жизненного цикла программы.
Увеличение номера сборки (versionCode): В Сборщике мобильных приложений 1С необходимо обязательно увеличить целочисленный номер версии versionCode. Номер версии для отображения (versionName) может изменяться по усмотрению разработчика (например, с 1.0 на 1.1), но versionCode обязан быть строго больше предыдущего значения.
Что происходит при первом запуске обновленного приложения
Проанализируем процесс инициализации новой версии конфигурации на устройстве пользователя после завершения загрузки пакета:
Запуск мобильной платформы: Пользователь открывает приложение. Платформа 1С обнаруживает, что версия конфигурации в ресурсах пакета отличается от версии структуры в локальной базе.
Реструктуризация базы данных: Платформа запускает автоматический процесс реструктуризации метаданных — добавляются новые справочники, документы, реквизиты или регистры.
Обработка критических изменений: Если разработчик удалил объекты метаданных, изменил типы существующих реквизитов или произвел изменения, потенциально ведущие к потере части данных, мобильная платформа выводит предупреждающее диалоговое окно. Пользователю предлагается подтвердить применение изменений.
Реакция на отказ пользователя: Если пользователь выбирает вариант «Нет», реструктуризация прерывается, и работа приложения штатно завершается. При каждом следующем старте запрос будет повторяться до тех пор, пока пользователь не согласится с изменениями либо не будет установлена совместимая сборка.
Создание резервной копии: Мобильная платформа 1С перед выполнением реструктуризации базы данных автоматически формирует резервную копию для предотвращения повреждения информационной базы при возникновении сбоев во время конвертации.
В зависимости от архитектуры мобильного решения можно применять различные подходы к доставке обновлений:
Мобильный клиент с автономным режимом: Если архитектура решения построена на базе мобильного клиента, бизнес-логика и метаданные могут обновляться динамически при синхронизации с основным сервером 1С. Публикация нового APK-файла требуется только при смене версии самой мобильной платформы.
Корпоративное обновление (Self-update): Для внутренних корпоративных приложений можно организовать скачивание актуального APK-файла напрямую с корпоративного веб-сервера. Разберем программный механизм загрузки и вызова системного установщика:
// Загрузка нового APK-пакета с сервера и запуск установки
ПараметрыHTTP = Новый Соответствие;
HTTPСоединение = Новый HTTPСоединение("corp-server.local", 443, , , , 30, Новый ЗащищенноеСоединениеOpenSSL);
ИмяВременногоФайла = КаталогВременныхФайлов() + "app-update.apk";
HTTPЗапрос = Новый HTTPЗапрос("/updates/app-release.apk");
HTTPОтвет = HTTPСоединение.Получить(HTTPЗапрос, ИмяВременногоФайла);
Если HTTPОтвет.КодСостояния = 200 Тогда
ЗапуститьПриложение("file://" + ИмяВременногоФайла);
КонецЕсли;
При использовании прямого обновления через ЗапуститьПриложение действуют те же правила целостности: цифровой сертификат и идентификатор пакета должны строго совпадать, а versionCode должен быть увеличен.