← На главную

Сборка мобильного приложения — процесс, который часто преподносится как «магия одной кнопки», особенно при использовании облачного сервиса 1С на портале ИТС. Однако на практике разработчики часто сталкиваются с ситуацией, когда процесс прерывается с пометкой «Собрано с ошибками». В этой статье мы подробно разберем, почему возникают сбои при компоновке Android-пакетов, как правильно настраивать идентификаторы и почему нельзя просто так «переключить» тип мобильного решения в уже созданном проекте.

Разбор ошибки Android resource linking failed и правил именования пакета

Проанализируем типичную ситуацию из лога сборки. Если в журнале вы видите сообщение Execution failed for task ':processSignReleaseResources', а ниже уточнение error: attribute 'package' in manifest tag is not a valid Android package name, значит, корень проблемы кроется в строке идентификатора приложения.

Выясним причину этой ошибки. В операционной системе Android каждое приложение должно иметь уникальный идентификатор (Package Name), который строится по правилам именования пакетов в языке Java. Рассмотрим основные требования к этой строке:

1. Иерархичность: Идентификатор должен состоять как минимум из двух сегментов, разделенных точкой. Например, com.mycompany.myorderapp.
2. Запрет на начальную точку: Имя пакета не может начинаться с точки. В логе автора мы видим идентификатор .ecookna. Именно лишняя точка в начале вызывает критический сбой LinkApplicationAndroidResourcesTask.
3. Допустимые символы: Разрешены только латинские буквы (желательно в нижнем регистре), цифры и подчеркивания. Сегменты не могут начинаться с цифр.
4. Зарезервированные слова: Нельзя использовать ключевые слова Java (например, int, abstract, class).

В облачном сборщике 1С полный идентификатор часто формируется динамически. Разберем по шагам, как это происходит: сервис берет «Префикс идентификатора» из общих настроек поставщика и добавляет к нему «Идентификатор» из конкретных настроек приложения. Если префикс оставлен пустым, а в поле идентификатора введена строка, начинающаяся с точки, сборщик послушно подставит её в AndroidManifest.xml, что и приведет к неудаче. Чтобы исправить ситуацию, укажите корректное доменное имя в формате ru.название_компании.название_приложения без ведущих и замыкающих точек.

Особенности смены типа сборки: Мобильный клиент против Мобильного приложения

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

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

Решение задачи будет следующим: если вам необходимо сменить тип сборки, не пытайтесь редактировать старую карточку приложения. Создайте в облаке новую запись с нуля, выберите нужный тип (Мобильное приложение или Мобильный клиент) и заново загрузите конфигурацию .cf. Это гарантирует чистоту сборки и правильное формирование всех внутренних ресурсов.

Решение проблемы «Черного экрана» и совместимость с новыми версиями Android

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

Современные смартфоны на базе Android 13 и 14 (API 33/34) предъявляют жесткие требования к безопасности. В частности, изменились механизмы запроса разрешений на использование мультимедиа. Если использовать старые версии платформы (например, ниже 8.3.20), приложение может зависнуть при попытке инициализировать драйвер камеры, так как не умеет корректно запрашивать новые системные привилегии.

Использование платформы версии 8.3.25 и выше решает эти проблемы, так как в ней:

• Реализована поддержка Camera2 API, что критично для новых модулей камер.
• Обновлены шаблоны запросов разрешений (Permissions) под требования Android 14.
• Используется актуальный стек сборки: Java 17 и Android SDK 34.

Технические нюансы: иконки, сплэш-скрины и логирование

Посмотрим на предупреждения в логах, касающиеся графической информации. Множество строк с пометкой ОТСУТСТВУЕТ для файлов типа icon-72x72.png или splash-480x854.png не блокируют сборку, но серьезно портят качество продукта. Рассмотрим, почему важно заполнять эти ресурсы:

1. Система Android использует разные иконки для разных плотностей пикселей (ldpi, mdpi, hdpi, xxhdpi). Если вы загрузили только одну картинку, система будет её масштабировать, что приведет к размытию.
2. Отсутствие сплэш-скринов (заставок) приводит к тому, что при загрузке тяжелого приложения пользователь будет видеть пустой экран, что часто воспринимается как зависание.

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

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