← На главную

При разработке и тестировании решений на базе 1С:Мобильной платформы разработчики часто используют быстрый способ запуска: устанавливают на планшет или смартфон универсальное приложение разработчика мобильной платформы и подключают информационную базу через веб-сервер без полной сборки автономного APK-пакета. Однако при попытке настроить и инициализировать встроенные драйверы оборудования (например, внешние компоненты для работы с фискальными регистраторами или сканерами) платформа выдает ошибку: «Не удалось загрузить драйвер устройства». При этом тот же самый драйвер в собранном автономном APK работает штатно.

Разберем детально, почему возникает данная ошибка, как устроена работа внешних компонент в среде Android и какие способы позволяют решить проблему или настроить правильный процесс отладки.

Причины возникновения ошибки при динамической загрузке драйвера

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

1. Ограничения безопасности операционной системы Android (W^X и SELinux). Начиная с Android 7.0 (API 24), в операционной системе действуют строгие ограничения на вызов функции dlopen() для динамических библиотек (файлов с расширением .so), расположенных в доступных для записи пользовательских каталогах приложения. Когда конфигурация запускается внутри контейнера разработчика, платформа пытается динамически скачать библиотеку с веб-сервера во временную рабочую папку и загрузить ее в память, что блокируется политиками безопасности ОС. В автономном APK-пакете библиотеки распаковываются в защищенный системный каталог lib/<архитектура>/, откуда динамическая загрузка разрешена.
2. Отсутствие необходимых системных разрешений в универсальном манифесте. Драйверам торгового оборудования для взаимодействия с физическими устройствами требуются специальные разрешения ОС: доступ к USB-хосту (android.permission.USB_PERMISSION), Bluetooth, определение местоположения для сканирования беспроводных сетей и доступ к сетевым сокетам. В универсальном контейнере разработчика активирован только базовый набор прав, тогда как при индивидуальной сборке пакета нужные разрешения явно указываются в манифесте приложения.
3. Блокировка передачи файлов внешних компонент веб-сервером. При подключении конфигурации мобильное приложение скачивает двоичные файлы внешних компонент отдельными HTTP-запросами из каталога публикации (например, по пути /Android/arm/). Если на веб-сервере (IIS, Apache) не зарегистрированы соответствующие MIME-типы, сервер вернет ошибку (404 или 403), и файл драйвера не будет получен клиентом.
4. Несоответствие архитектуры процессора (ABI). Мобильные устройства работают на различных архитектурах (armeabi-v7a, arm64-v8a, x86). Если двоичный макет внешней компоненты содержит библиотеки только для 32-битной архитектуры arm, а на устройство установлен 64-битный клиент разработчика, загрузка библиотеки завершится сбоем.

Способ 1. Настройка MIME-типов на веб-сервере публикации

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

Разберем по шагам добавление MIME-типов для веб-сервера:

1. Откроем оснастку управления веб-сервером (для IIS — «Диспетчер служб IIS», для Apache — конфигурационный файл httpd.conf или .htaccess).
2. Перейдем в раздел настройки типов MIME для каталога опубликованной мобильной базы.
3. Добавим правила сопоставления расширений со следующим типом содержимого:

   Расширение: .so — Тип MIME: application/octet-stream

   Расширение: .apk — Тип MIME: application/octet-stream

   Расширение: .a — Тип MIME: application/octet-stream

   Расширение: .dylib — Тип MIME: application/octet-stream

4. Перезапустим службу веб-сервера для применения настроек.
5. Проверим корректность отдачи: откроем мобильный браузер на целевом планшете и перейдем по прямому URL к файлу библиотеки в подпапке публикации (например, http://адрес_сервера/MobileApp/Android/arm/driver.so). Файл должен успешно скачиваться без ошибок 404 или 403.

Способ 2. Сборка отладочного APK-пакета (рекомендуемое решение)

Полноценная работа низкоуровневых внешних компонент Native API (Bluetooth, USB, фискальные регистраторы) гарантируется только в составе собранного и установленного APK-пакета приложения. Чтобы не терять возможность интерактивной отладки кода при работе с реальным оборудованием, настроим отладочную сборку.

Выполним следующие шаги:

1. Откроем инструмент «Сборщик мобильных приложений» в среде 1С.
2. В свойствах собираемого мобильного приложения перейдем на вкладку параметров сборки и включим признак «Режим отладки».
3. Укажем адрес и порт отладочного сервера (компьютера с Конфигуратором 1С).
4. В настройках разрешений манифеста отметим все необходимые права доступа для используемого оборудования (работа с Bluetooth, доступ к портам USB, использование сети).
5. Соберем и подпишем отладочный APK-пакет, после чего установим его на мобильное устройство через кабель (с помощью утилиты adb install) или передав файл на планшет.
6. На компьютере разработчика запустим Конфигуратор и настроим проброс портов отладки через Android Debug Bridge (ADB), выполнив в консоли команду: adb forward tcp:9222 tcp:9222
7. Запустим установленное приложение на планшете. Мобильное приложение подключится к отладчику Конфигуратора, при этом все вызовы драйверов и внешних компонент будут выполняться в штатном доверенном окружении ОС Android.

Способ 3. Проверка состава двоичного макета и архитектуры платформы

Если ошибка сохраняется даже в собранном APK, выясним причину внутри самого драйвера:

1. Извлечем макет внешней компоненты из конфигурации, сохранив его как ZIP-архив.
2. Проверим наличие файла описания (manifest.xml или info.xml) и состав скомпилированных библиотек. Убедимся, что внутри архива присутствуют папки для архитектур Android-arm и Android-arm64.
3. Проверим разрядность дистрибутива мобильной платформы, установленной на планшете: она должна строго совпадать с поддерживаемой разрядностью библиотеки драйвера.