Сборка мобильного приложения на платформе 1С:Предприятие — это сложный многоэтапный процесс, в котором задействованы не только инструменты 1С, но и компоненты Android SDK, Java и Gradle. Одной из самых коварных проблем, с которой сталкиваются разработчики, является ошибка на этапе processSignReleaseMainManifest. Проанализируем ситуацию: визуально сборка идет успешно, но в определенный момент Gradle выдает фатальный сбой, сообщая о неудачном слиянии манифестов (Manifest merger failed).
Рассмотрим подробнее лог ошибки. Как правило, в нем содержится множество предупреждений и одна критическая ошибка, выглядящая примерно так: Error: Element uses-permission#android.permission.BLUETOOTH_SCAN duplicated. Это означает, что в итоговом файле AndroidManifest.xml, который формируется «на лету» из различных источников, одно и то же разрешение было объявлено несколько раз с несовпадающими параметрами или просто в избыточном количестве, что современные инструменты сборки Android считают недопустимым.
Разберем по шагам, как формируется мобильное приложение. Сборщик берет за основу ядро мобильной платформы, добавляет туда вашу конфигурацию и — что критически важно — внешние компоненты (драйверы торгового оборудования, сканеров, принтеров). Каждая такая компонента содержит свой мини-манифест (файл ANDROID_MANIFEST_EXTENTIONS.XML). Инструмент Manifest Merger пытается объединить все эти файлы в один большой AndroidManifest.xml. Если мобильная платформа 1С уже запрашивает разрешение на использование Bluetooth, а следом за ней это же разрешение запрашивает драйвер сканера, возникает дублирование.
Проанализируем ситуацию с новыми версиями Android (12 и выше). В них изменились требования к разрешениям Bluetooth (появились BLUETOOTH_SCAN, BLUETOOTH_CONNECT и BLUETOOTH_ADVERTISE). Старые внешние компоненты могут содержать жестко прописанные старые разрешения, которые конфликтуют с новыми правилами платформы. Именно это мы и видим в логах: система сообщает, что элемент uses-permission продублирован в разных строках файла.
Самый простой и эффективный способ решить проблему — это обновить Сборщик мобильных приложений до версии 8.3.25 или более поздней. Посмотрим, почему это помогает. Начиная с версии 8.3.25, разработчики 1С внедрили в Сборщик механизм автоматической нормализации манифеста. Теперь Сборщик перед передачей проекта в Gradle самостоятельно анализирует результирующий XML-файл и вычищает из него дубликаты разрешений, предотвращая конфликт Manifest Merger.
Важно отметить нюанс совместимости версий. Рассмотрим правила, которыми стоит руководствоваться:
Если по каким-то причинам вы не можете обновить Сборщик, или автоматическая очистка не справляется, разберем более трудоемкий, но надежный метод ручного исправления. Проблема локализована во внешних компонентах, которые включены в вашу конфигурацию (например, Драйвер1СЭквайринговыеТерминалыСбербанк или драйверы АТОЛ).
Выполним следующие действия для каждой проблемной компоненты:
.zip.ANDROID_MANIFEST_EXTENTIONS.XML.
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
</manifest>
android.permission.BLUETOOTH дублируется, смело удаляем эту строку из файла компоненты.Важный совет: не удаляйте все разрешения подряд. Оставляйте те, которые не упоминаются в логе ошибок как дубликаты, иначе компонента может потерять доступ к необходимым функциям устройства.
Посмотрим на другие аспекты, которые могут влиять на успех операции processSignReleaseMainManifest. В логе часто фигурируют предупреждения о версиях Java и Android SDK. Разберем оптимальные параметры:
Выбор JDK: Несмотря на то, что старые инструкции рекомендуют JDK 8, для современных версий мобильной платформы (8.3.24 и выше) и инструментов сборки Android (AGP) настоятельно рекомендуется использовать JDK 11. Это обеспечивает более стабильную работу скриптов Gradle при слиянии ресурсов и манифестов.
Очистка кэша: Gradle активно кэширует результаты работы. Если вы исправили манифесты в макетах, но сборка все равно падает с той же ошибкой, проанализируем состояние рабочего каталога. Обязательно очищайте папку, указанную в поле Рабочий каталог (например, C:\Temp\MobileAppBuilder\), перед каждой новой попыткой после внесения правок в код или макеты.
Параметры gradle.properties: Убедимся, что в настройках сборки включена поддержка AndroidX и Jetifier, что критично для современных внешних компонент:
android.useAndroidX = true
android.enableJetifier = true
Подведем итог. Ошибка processSignReleaseMainManifest FAILED — это сигнал о том, что в итоговом манифесте приложения возникла «каша» из повторяющихся прав доступа. Использование Сборщика мобильных приложений версии 8.3.25 является «золотым стандартом» решения, так как он берет на себя всю рутину по очистке XML-структур. В экзотических случаях всегда остается возможность ручного «хирургического» вмешательства в манифесты драйверов через ZIP-архивы макетов.