Разработка мобильных приложений на платформе 1С:Предприятие — это удобный способ быстро автоматизировать бизнес-процессы на смартфонах и терминалах сбора данных (ТСД). Однако на этапе сборки готового пакета APK разработчики часто сталкиваются с неприятной ситуацией: приложение, которое отлично работало в режиме отладки через веб-сервер на мобильной платформе-клиенте, после сборки в полноценный APK отказывается запускаться на реальных устройствах. Оно устанавливается без ошибок, но при попытке открытия мгновенно «вылетает» (закрывается), даже не доходя до экрана выбора информационной базы или авторизации.
В этой статье мы подробно разберем, почему происходят такие критические сбои, проанализируем неочевидные технические нюансы мобильной платформы 1С версий 8.3.16 и 8.3.17+, а также по шагам изучим методы точной диагностики подобных ошибок с помощью инструментов разработчика Android.
Как показывает практика практикующих разработчиков, одной из самых частых причин мгновенного вылета приложения являются внутренние баги или изменения в конкретных релизах мобильной платформы 1С. Например, сборка приложения на релизе платформы 8.3.17.67 может приводить к аварийному завершению работы на многих смартфонах, в то время как использование проверенного временем релиза 8.3.16.42 полностью решает проблему без изменения кода конфигурации.
Выясним причину такого поведения. При переходе между мажорными версиями платформы (из 8.3.16 в 8.3.17 и далее) разработчики 1С существенно меняют внутренние механизмы взаимодействия с операционной системой Android, обновляют библиотеки сборки и требования к окружению. Если вы столкнулись с моментальным падением приложения, первым делом рекомендуется протестировать сборку на нескольких разных релизах мобильной платформы 1С.
Любое мобильное устройство работает на процессоре с определенной архитектурой. Для современных смартфонов (включая устройства марок Huawei, Honor, Xiaomi, Samsung) стандартом является архитектура ARM. При этом существуют ее 32-битная (ARMv7) и 64-битная (ARM64) версии. Эмуляторы операционной системы Android для ПК (например, BlueStacks, LDPlayer или встроенный эмулятор Android Studio) часто используют архитектуру x86.
Рассмотрим подробнее, как это влияет на работоспособность собранного приложения:
java.lang.UnsatisfiedLinkError).Для исключения этой проблемы при создании дистрибутива в Сборщике мобильных приложений всегда выбирайте мульти-сборку под несколько архитектур (вариант «Android 4in1») или точно сопоставляйте целевую архитектуру процессора вашего тестируемого устройства.
Начиная с версии мобильной платформы 1С 8.3.17, целевая версия Android SDK (Target SDK) была принудительно повышена разработчиками 1С до уровня API 29 (Android 10), а в более поздних версиях — до API 30 (Android 11) и выше. Это требование продиктовано правилами публикации приложений в магазине Google Play.
С повышением Target SDK операционная система включает жесткие механизмы защиты пользовательских данных:
/sdcard/ или /Download/) по абсолютным путям.Чтобы избежать подобных вылетов, адаптируйте конфигурацию 1С для работы с файлами. Используйте только разрешенные платформой методы получения путей к каталогам. Посмотрим на пример правильного получения пути к файлам во встроенном языке 1С:
// Правильное определение путей для записи и чтения файлов на мобильном устройстве
ИмяФайлаНастроек = "settings.json";
КаталогПриложения = КаталогДокументов();
ПолныйПутьКФайлу = ОбъединитьПути(КаталогПриложения, ИмяФайлаНастроек);
// Запись файла в изолированное хранилище приложения
ТекстовыйДокумент = Новый ТекстовыйЗапись(ПолныйПутьКФайлу, КодировкаТекста.UTF8);
ТекстовыйДокумент.ЗаписатьСтроку(ДанныеНастроекВФорматеJSON);
ТекстовыйДокумент.Закрыть();
Метод КаталогДокументов() всегда возвращает путь к изолированной папке вашего конкретного приложения, доступ к которой разрешен операционной системой по умолчанию и не вызывает аварийных блокировок процесса.
Сам по себе «Сборщик мобильных приложений» от 1С является лишь графической оболочкой-конфигурацией, которая автоматизирует вызовы внешних утилит компиляции: Android SDK Tools, компилятора Gradle и комплекта разработки Java (JDK). При смене версии мобильной платформы 1С внутри Сборщика (например, при попытке собрать приложение на платформе 8.3.17 вместо 8.3.16) критически важно обновить и все сопутствующее окружение:
Если приложение вылетает, а визуальных сообщений об ошибках нет, единственным надежным способом узнать правду является анализ системного лога операционной системы Android. Для этого используется утилита ADB (Android Debug Bridge), входящая в состав Android SDK.
Разберем по шагам, как правильно настроить отслеживание логов, так как стандартный запуск команды adb logcat выводит гигантский поток системной информации, в котором легко потеряться.
Шаг 1. Подготовка мобильного устройства
На телефоне необходимо включить режим разработчика. Для этого перейдите в Настройки -> О телефоне и быстро нажмите 7-10 раз на пункт "Номер сборки". После появления уведомления "Вы стали разработчиком", перейдите в меню Система и обновления -> Для разработчиков и активируйте тумблер "Отладка по USB".
Шаг 2. Подключение к ПК
Подключите телефон к компьютеру по кабелю USB или настройте подключение по беспроводной сети. Проверим успешность сопряжения через командную строку Windows (cmd), перейдя в папку с установленным ADB:
cd C:\Android\Platform-Tools\
adb.exe devices
В консоли должен отобразиться идентификатор вашего устройства со статусом device. Если статус устройства отображается как unauthorized, разблокируйте экран телефона и подтвердите запрос на доверие к данному компьютеру.
Шаг 3. Запуск фильтрации логов на критические ошибки
Чтобы не просматривать миллионы лишних строк системного кэша, запустим фильтрацию вывода логов. Нам нужно отловить момент аварийного завершения процесса (так называемый Crash). В Android все подобные события помечаются тегом AndroidRuntime и уровнем логирования Fatal Exception.
Запустите в консоли следующую команду перед стартом приложения на телефоне:
adb.exe logcat *:E | findstr "AndroidRuntime"
Эта команда отфильтрует системный лог и покажет только ошибки уровня Error (E), содержащие информацию о критическом падении среды выполнения Java. Запустите приложение на телефоне. В момент вылета в консоли появится подробный стек вызовов (Stack Trace), в котором будет указан конкретный класс Java или системная библиотека, вызвавшая сбой (например, ошибка обращения к памяти процессора или отсутствие прав доступа к файлу базы данных).
Шаг 4. Фильтрация по имени пакета приложения
Если вы хотите записать полный лог работы именно вашего приложения 1С, используйте фильтрацию по имени его пакета (идентификатору, который задается при сборке приложения, например, com.company.mobileapp). Для этого воспользуемся следующей конструкцией в командной строке:
adb.exe logcat --pid=$(adb shell pidof -s com.company.mobileapp) > app_log.txt
Эта команда автоматически определит идентификатор запущенного процесса вашего приложения (PID) и запишет весь его лог в текстовый файл app_log.txt для последующего детального анализа в текстовом редакторе.
Если собранный APK-файл мобильного приложения 1С закрывается при запуске, рекомендуем придерживаться следующего алгоритма действий:
8.3.16.42). Если это помогло — дело в несовместимости конфигурации или сборочного окружения с требованиями новой платформы 1С.КаталогДокументов().adb logcat. Пятиминутная настройка отладки по USB сэкономит вам часы бесцельного перебора версий платформы, сразу указав на строчку кода или системный компонент, из-за которого происходит аварийное завершение процесса.