При разработке мобильных приложений на платформе 1С для работы с торговым оборудованием, например, терминалами сбора данных (ТСД), часто возникает задача перехвата событий от аппаратных кнопок. Старые инструкции и руководства рекомендуют для этого модифицировать файл permissions.xml, добавляя в него необходимые разрешения или фильтры намерений (intent-filter). Однако на современных версиях платформы (например, 8.3.24 и выше) разработчики сталкиваются с проблемой: этого файла попросту нет в папке сборки prjandroid-arm. Давайте разберемся, почему так произошло и как решить эту задачу современными методами.
Проанализируем ситуацию. Файл permissions.xml действительно использовался в старых версиях мобильной платформы 1С. Он служил простым механизмом для добавления кастомных разрешений и других элементов в итоговый манифест Android-приложения (AndroidManifest.xml) на этапе сборки.
Со временем платформа развивалась, механизм сборки усложнялся и становился более стандартизированным. В новых версиях этот файл был упразднен. Теперь платформа использует другие, более структурированные подходы для управления манифестом приложения. Поэтому, если вы работаете со свежей версией платформы 1С, поиски файла permissions.xml не дадут результата.
Что же делать, если нужно добавить специфические настройки, как, например, intent-filter для отслеживания широковещательных сообщений от сканера ТСД? Рассмотрим два пути решения: один быстрый и рискованный, другой — рекомендуемый и надежный.
Как выяснилось в ходе обсуждения, часть настроек, которые ранее могли находиться в permissions.xml, теперь могут быть заданы через другой служебный файл — maker-settings.xml. Он также находится в каталоге сборки мобильного приложения.
Важно понимать: этот подход является крайне нерекомендуемым и должен использоваться с большой осторожностью, возможно, только для временных тестов или в безвыходной ситуации. Выясним причины, почему к этому методу стоит относиться скептически:
maker-settings.xml являются внутренней реализацией сборщика мобильных приложений 1С. Нет никакой официальной документации по его формату.Тем не менее, если вам нужно срочно проверить гипотезу, вы можете исследовать этот файл и попробовать внести в него необходимые изменения по аналогии со структурой AndroidManifest.xml. Для автора исходного вопроса этот способ оказался рабочим и помог решить проблему "здесь и сейчас".
Профессиональный и правильный подход к решению подобных задач в современных версиях мобильной платформы — это использование внешних компонент, написанных с использованием Native API. Этот механизм позволяет интегрировать в 1С-приложение нативный код (Java/Kotlin), который имеет полный доступ ко всем возможностям операционной системы Android.
Вся логика, специфичная для оборудования или ОС, инкапсулируется внутри компоненты. Это делает ваше решение модульным, поддерживаемым и независимым от внутренних механизмов платформы 1С.
Рассмотрим, как с помощью внешней компоненты решить задачу перехвата нажатий аппаратных кнопок ТСД.
Существует два основных способа перехвата событий от оборудования внутри нативной компоненты.
Это самый распространенный и правильный способ для работы с профессиональным оборудованием, таким как ТСД. Производители (например, Zebra, Honeywell, Urovo и др.) встраивают в свои прошивки специальные сервисы. Когда пользователь нажимает физическую кнопку сканирования, этот сервис считывает штрихкод и отправляет данные в систему через широковещательное сообщение (Broadcast Intent). Наша задача — "поймать" это сообщение.
Рассмотрим по шагам, как это работает:
BroadcastReceiver. Внутри компоненты создается класс-наследник от android.content.BroadcastReceiver. Его метод onReceive() будет выполняться каждый раз, когда система получит соответствующее сообщение.IntentFilter. В него добавляются специальные "действия" (actions) — уникальные строки, которые идентифицируют событие от сканера. Например, для одного из производителей это может быть строка "com.xcheng.scanner.action.BARCODE_DECODING_BROADCAST". Эти "действия" и имена передаваемых данных (extras) всегда можно найти в документации (SDK) от производителя ТСД.BroadcastReceiver регистрируется в системе вместе с фильтром. Это можно сделать либо программно в коде, либо декларативно в файле AndroidManifest.xml самой компоненты.BroadcastReceiver его перехватывает, извлекает из него полезные данные (например, строку штрихкода) и инициирует внешнее событие в 1С.ОбработкаВнешнегоСобытия), который получает данные от компоненты и выполняет необходимую бизнес-логику.Ключевое преимущество: вам не нужно ничего редактировать в файлах платформы 1С. Если вашей компоненте нужны разрешения или intent-filter, вы прописываете их в ее собственном файле AndroidManifest.xml. При сборке мобильного приложения сборщик 1С автоматически и корректно объединит манифест вашего приложения и манифесты всех подключенных компонент.
Этот способ более универсальный, но и более сложный. Он применяется, когда ТСД не транслирует нужные события через Broadcast'ы. AccessibilityService — это специальный фоновый сервис Android, который, после получения разрешения от пользователя, может перехватывать события взаимодействия с интерфейсом, включая нажатия физических кнопок.
Как это работает:
android.accessibilityservice.AccessibilityService.onKeyEvent, и анализирует, какая кнопка была нажата.BroadcastReceiver-ом в вашей основной внешней компоненте.Этот метод требует от пользователя дополнительных действий по настройке и более сложен в реализации, но может быть единственным выходом для некоторых моделей устройств.
Подведем итог. Проблема с отсутствием файла permissions.xml вызвана эволюцией мобильной платформы 1С. Для ее решения у нас есть два пути:
maker-settings.xml: Быстрое, но нестабильное и рискованное решение. Может подойти для экстренных случаев или тестов, но не для промышленной эксплуатации.Для серьезных проектов, особенно связанных с интеграцией торгового оборудования, всегда выбирайте путь создания внешней компоненты. Это инвестиция времени, которая окупится надежностью и простотой поддержки вашего решения в будущем.