Как исправить ошибку «Unable to make field private final java.lang.String java.io.File.path accessible» при сборке мобильного приложения 1С?

При разработке и тиражировании мобильных решений на платформе 1С программисты часто сталкиваются с трудностями на этапе финальной сборки пакета (APK или сообщений для iOS). Одной из самых коварных ошибок является сбой при выполнении задачи :processSignReleaseMainManifest. Эта проблема может поставить в тупик даже опытного разработчика, так как текст ошибки указывает на внутренние механизмы Java, которые, казалось бы, не имеют прямого отношения к коду 1С.

В данной статье мы подробно разберем, почему возникает эта ошибка, как версия JDK влияет на стабильность сборщика и какие практические шаги помогут успешно собрать мобильное приложение.

Анализ исходной ситуации и текста ошибки

Рассмотрим типовой сценарий. Разработчик использует «Сборщик мобильных приложений» версии 8.3.21.41, установлены Android SDK 31 или 33, а в качестве среды исполнения выбрана JDK 18.0.2.1. При попытке генерации релизного файла система выдает следующее сообщение:

FAILURE: Build failed with an exception.
Execution failed for task ':processSignReleaseMainManifest'.
> Unable to make field private final java.lang.String java.io.File.path accessible: module java.base does not "opens java.io" to unnamed module @9e357c3

Проанализируем ситуацию: корень проблемы кроется в системе модулей Java (Project Jigsaw), которая была введена еще в Java 9, но стала максимально строгой в версиях 16 и выше. Ошибка говорит о том, что инструменты сборки (Gradle и его плагины), используемые платформой 1С, пытаются получить доступ к защищенным полям системного класса java.io.File через рефлексию. Начиная с Java 17 и 18, такие операции запрещены по умолчанию для обеспечения безопасности и целостности среды.

Решение №1: Приведение версии JDK к рекомендованному стандарту

Первое, на что мы должны обратить внимание — это совместимость компонентов. Для версий платформы 1С 8.3.21 и ниже использование JDK 18 является избыточным и часто вредным. Официально рекомендуемой и наиболее стабильной версией для сборки мобильных приложений 1С остается JDK 11.

Выясним, почему это важно. JDK 11 (LTS-версия) обладает необходимой гибкостью и позволяет инструментам Gradle выполнять операции рефлексии, которые требуются плагинам Android для обработки манифеста приложения. Рассмотрим алгоритм действий по исправлению:

1. Удалим текущую версию JDK 18 из системы.
2. Скачаем и установим OpenJDK 11 или Oracle JDK 11.
3. В настройках «Сборщика мобильных приложений» 1С укажем новый путь к каталогу JDK 11.
4. Обязательно проверим системную переменную JAVA_HOME, она также должна указывать на версию 11.

Решение №2: Использование ключей доступа к модулям Java

Если по каким-то причинам переход на JDK 11 невозможен, проанализируем способ «обхода» ограничений безопасности Java 18. Мы можем явно разрешить доступ к модулям, на которые жалуется сборщик. Для этого используются специальные параметры запуска JVM.

Посмотрим на пример параметров, которые необходимо добавить в настройки сборки (через переменные окружения GRADLE_OPTS):

--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED

Эти флаги заставляют виртуальную машину Java «открыть» внутренние пакеты для неименованных модулей (в данном случае — для Gradle). Это должно устранить ошибку Unable to make field... accessible.

Решение №3: Работа с ключами разработчика и сетевыми ограничениями

Как показывает практика и опыт участников обсуждения, даже после исправления проблем с JDK сборка может прерываться на этапе processSignReleaseMainManifest. Это происходит потому, что на данном этапе Gradle не только проверяет структуру AndroidManifest.xml, но и подготавливает данные для подписи приложения.

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

1. Перегенерация ключа разработчика: В самом сервисе сборщика или в локальной базе сборщика необходимо заново создать (или перевыбрать) сертификат, которым подписывается приложение. Старые или некорректно импортированные ключи могут вызывать неочевидные сбои в манифесте.
2. Использование VPN: Это критически важный момент для разработчиков из РФ. Процесс сборки Android-приложений неразрывно связан с загрузкой зависимостей из репозиториев Google (Google Maven Repository). При блокировке доступа к этим ресурсам Gradle выдает ошибки, которые могут маскироваться под технические сбои манифеста. Включение VPN на этапе сборки позволяет корректно загрузить все необходимые build-tools и библиотеки проверки подписей.

Дополнительные рекомендации по очистке окружения

Часто после неудачных попыток в системе остаются «хвосты», которые мешают новой сборке даже после исправления всех настроек. Проанализируем ситуацию с кэшированием. Мы рекомендуем выполнить следующие действия перед финальной попыткой:

• Полностью удалите содержимое папки build внутри рабочего каталога вашего проекта мобильного приложения.
• Очистите глобальный кэш Gradle. Обычно он находится по пути C:\Users\ИмяПользователя\.gradle\caches.
• В «Сборщике мобильных приложений» выполните команду очистки временных файлов (если предусмотрено интерфейсом конкретной версии).

Подводя итог, можно сказать, что стабильная сборка мобильного приложения 1С — это результат баланса между версией платформы 1С, версией JDK (лучше использовать 11) и стабильным доступом к серверам Google. Совместное применение правильной версии Java, использование VPN и обновление ключей разработчика гарантирует успешное завершение процесса создания мобильного решения.