← На главную

Процесс сборки мобильного приложения на платформе 1С:Предприятие часто сопровождается техническими сложностями, связанными с анализом состава расширений и настройкой окружения Android. Ошибки могут возникать на разных этапах: от статического анализа кода и инициализации виртуальной машины Java до слияния манифестов при использовании внешних компонент. Разберем наиболее частые проблемы, с которыми сталкиваются разработчики при использовании "Сборщика мобильных приложений" версии 8.3.24.68, и найдем эффективные способы их решения.

Устранение ошибки нехватки памяти: Could not reserve enough space for object heap

Одной из самых распространенных ошибок является невозможность зарезервировать достаточное количество оперативной памяти для виртуальной машины Java (JVM). В логах это выглядит следующим образом: Error occurred during initialization of VM. Could not reserve enough space for 1572864KB object heap. Проанализируем причину возникновения данной ситуации.

Основная причина заключается в использовании 32-разрядной версии JDK, что подтверждается анализом зависимостей конфигурации. Архитектура x86 накладывает жесткие ограничения на размер непрерывного блока памяти, который может выделить процесс. Даже если на вашем компьютере 32 ГБ оперативной памяти, 32-битная Java не сможет выделить запрашиваемые 1.5 ГБ (1536 MB) под нужды Gradle.

Для решения этой проблемы выполним следующие шаги:

1. Переход на 64-битную версию JDK: Установим современную версию Java. Хотя долгое время стандартом была версия 1.8, для платформы 8.3.24 и выше рекомендуется использовать JDK 11 или JDK 17 (64-bit). Например, openjdk version 17.0.11.
2. Проверка путей в Сборщике: В информационной базе "Сборщик мобильных приложений" проверим поле Путь к Java. Он должен указывать на корень установленной 64-битной JDK.
3. Настройка параметров JVM: Если по какой-то причине переход на 64-битную версию невозможен, или памяти все равно не хватает, мы можем отредактировать настройки самого Сборщика. В конфигурации Сборщика в коде определены параметры запуска, где для 32-х и 64-х битных систем задаются разные лимиты. Однако наиболее правильным путем будет создание или редактирование файла gradle.properties в рабочей директории сборки, где можно указать параметр:

org.gradle.jvmargs=-Xmx1024m

Это ограничит максимальный размер "кучи" (heap) до 1 ГБ, что позволит 32-битному процессу успешно стартовать, хотя для крупных проектов этого может оказаться недостаточно.

Решение конфликтов в AndroidManifest.xml при использовании внешних компонент

Следующая критическая точка — этап слияния манифестов (Manifest Merger). Ошибка Execution failed for task ':processSignReleaseMainManifest' часто сопровождается сообщением о дублировании элементов. Рассмотрим типичный пример конфликта разрешений, возникающий из-за внешних компонент для работы с Bluetooth.

Представим ситуацию, когда в манифесте основной мобильной платформы и в манифесте внешней компоненты (библиотеки) одновременно объявлено одно и то же разрешение, например, ACCESS_WIFI_STATE. Система сборки Gradle не всегда может корректно объединить эти записи, если они имеют разные атрибуты или объявлены внутри разных узлов.

Разберем алгоритм исправления внешней компоненты:

1. Выгрузим файл внешней компоненты (обычно это .zip или .cfe, внутри которой лежит архив с нативными библиотеками) из конфигуратора 1С на локальный диск.
2. Распакуем содержимое компоненты. Нам нужно найти файл AndroidManifest.xml, относящийся к Android-части компоненты.
3. Откроем XML-файл и найдем дублирующуюся строку. Например:

<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />

4. Удалим эту строку, если мы уверены, что данное разрешение уже запрашивается основной платформой.
5. Запакуем компоненту обратно в архив, сохраняя исходную структуру папок, и загрузим обновленный файл в конфигурацию 1С.
6. После обновления конфигурации запустим процесс сборки в Сборщике мобильных приложений заново.

Оптимизация процесса сборки с использованием новой версии Сборщика

Если ручная правка манифестов кажется слишком трудоемкой, или если вы сталкиваетесь с множественными конфликтами в разных компонентах, рассмотрим альтернативный вариант. Начиная с версии платформы 8.3.25, механизмы Сборщика мобильных приложений были значительно доработаны.

Важный нюанс совместимости: Сборщик мобильных приложений версии 8.3.25 может собирать приложения на базе мобильных платформ 8.3.24 и ниже. При этом нам не требуется обновлять основную технологическую платформу 1С, на которой работают пользователи, до 25-й версии. Достаточно развернуть базу Сборщика на новой версии платформы.

Преимущества использования Сборщика 8.3.25:

• Автоматическое разрешение конфликтов дублирующихся разрешений (permissions) в манифесте.
• Улучшенная поддержка актуальных версий Android SDK (API Level 33 и 34).
• Встроенная поддержка более новых версий Gradle и JDK 17 "из коробки".

Настройка Android SDK и переменных окружения

Для стабильной работы сборки убедимся, что установлены все необходимые компоненты в Android Studio. Нам потребуются:

1. Android SDK Platform: Версия должна соответствовать той, что указана в настройках мобильного приложения (например, 33).
2. Android SDK Build-Tools: Рекомендуется устанавливать версии, максимально близкие к целевой (например, 33.0.1).
3. Android SDK Command-line Tools (latest): Это критически важный компонент. Без него Сборщик 1С часто не может обнаружить установленные SDK и выдает неинформативные ошибки.

Также проанализируем системные переменные. Переменная JAVA_HOME должна указывать на путь к 64-битной JDK, а в системной переменной Path должен присутствовать путь к папке bin внутри JDK. Это гарантирует, что Gradle, запускаемый Сборщиком, будет использовать именно ту версию Java, которую мы настроили, а не встроенную JRE от Android Studio или старую 32-битную версию.

В случае возникновения ошибки Unable to start the daemon process, рекомендуем очистить кэш Gradle. Для этого перейдем в папку профиля пользователя C:\Users\ИмяПользователя\.gradle и удалим содержимое папки daemon. Это сбросит состояние фоновых процессов, которые могли зависнуть или блокировать память после неудачных попыток сборки.

Следуя этим шагам — переходу на 64-битную JDK 17, очистке манифестов внешних компонент и, при необходимости, обновлению версии Сборщика до 8.3.25 — мы обеспечим стабильную и предсказуемую сборку мобильного приложения на платформе 1С.