Подпись Android-приложения Unreal Engine для Quest

Если коротко:

Краткий ответ на запрос «Unreal Engine Android подпись приложения» дан с опорой на официальные источники; конкретная совместимость и версии требуют проверки перед действием.

Зачем нужна подпись Android-сборки

Android принимает устанавливаемые приложения только как подписанные пакеты. В Unreal Engine настройки подписи относятся к выпуску и распространению сборки, а не к VR-функциям Quest. Неверно настроенный ключ может не позволить установить или обновить приложение, поэтому его нельзя хранить в репозитории или передавать вместе с проектом.

Что подготовить

Нужны keystore, alias и пароли, которые соответствуют политике команды и каналу публикации. Сначала определите, какая подпись используется для тестовых сборок и какая, для релиза. Подмена ключа после публикации может повлиять на возможность обновления уже установленного приложения, поэтому решение о ключе принимает владелец релизного процесса.

В Unreal Engine путь к keystore и параметры подписи указывают в Android-настройках проекта согласно актуальной документации версии движка. После заполнения полей соберите тестовый пакет и установите его на отдельное устройство. Не проверяйте выпускную подпись только успешной компиляцией: важна именно установка и обновление пакета.

Безопасный рабочий порядок

Создайте или получите одобренный командой keystore.
Храните секреты вне исходного кода и ограничьте доступ.
Настройте Android-параметры в конкретной версии Unreal Engine.
Проверьте тестовую установку и, при необходимости, обновление прежней сборки.
Зафиксируйте владельца ключа и резервный процесс восстановления.

Не публикуйте в инструкциях реальные пароли, alias и файлы ключей. Для Meta Quest дополнительно сверяйте формат и канал загрузки с документацией платформы: требования к распространению могут меняться.

Проверка без утечки секретов

После настройки подписи собирайте отдельный тестовый пакет и проверяйте установку на устройстве, а затем, обновление предыдущей тестовой версии, если это важно для канала распространения. Успех компиляции не доказывает, что Android примет подпись. Для диагностики сохраняйте сообщения сборки, но удаляйте из них пароли, пути к защищённому хранилищу и значения переменных окружения.

Ключ должен иметь владельца и резервную процедуру доступа. Потеря релизного ключа может затронуть последующие обновления, поэтому его нельзя заменять без решения владельца продукта. Конкретные поля и инструменты Unreal Engine зависят от версии движка; перед выпуском сверяйте актуальную документацию Unreal, Android и платформы распространения.

Источники

Что именно подписывается

Unreal Engine Android подпись приложения, это не настройка VR-рендера, а часть выпуска Android-сборки. Android требует цифровую подпись APK перед установкой или обновлением. Подпись связывает выпуск с ключом: если обновление подписано другим ключом, оно не может штатно заменить уже установленное приложение с тем же идентификатором. Поэтому сначала определяют, какой канал доставки нужен: локальная проверка через adb, внутреннее тестирование, магазин приложений или распространение в экосистеме Meta. Эти варианты могут требовать разные форматы и процедуры; их нельзя описывать как один и тот же шаг.

В Unreal Engine настройки Distribution Signing включают данные keystore, alias и пароли. Документация Epic указывает размещение файла keystore в <Project>/Build/Android; точные поля и интерфейс зависят от версии движка. Перед действиями зафиксируйте версию Unreal Engine, Android SDK/NDK, целевой runtime и способ доставки. Не копируйте инструкцию для другой версии без сверки названий полей в актуальной документации Epic.

Разделите debug и release

Для разработки и для распространяемой сборки нужны разные цели. Debug-пакет может быть удобен для локальной проверки, но не следует считать его готовым релизом. Release-процесс должен использовать согласованный ключ, версию приложения, package name и подходящий формат артефакта. Unreal Engine способен собирать Android App Bundle (AAB), но выбор AAB или APK определяется правилами конкретного канала доставки и целью сборки. Перед упаковкой проверьте требования площадки, target API и формат, а не подменяйте эту проверку настройками проекта.

Не смешивайте публикацию в Google Play, загрузку в Meta Horizon Store/App Lab и sideload через adb. У них могут различаться проверка, формат загрузки, каталог устройств, требования к метаданным и порядок распространения. Даже если Android-пакет успешно устанавливается вручную, это не доказывает, что он пройдёт проверку магазина или появится на нужной гарнитуре.

Подготовьте ключ и доступ к нему

Создайте или получите keystore только по согласованной процедуре команды. У ключа должен быть владелец, понятное место резервного хранения и ограниченный доступ. Потеря ключа релизной подписи может осложнить последующие обновления приложения. Не создавайте новый ключ «для быстрого исправления», пока не проверите, какой ключ использовался для уже распространённой версии.

Сам файл keystore и пароли нельзя помещать в Git, в публичные архивы, скриншоты задач или логи сборки. Добавьте секретные файлы в исключения репозитория, храните доступ в утверждённом хранилище секретов и передавайте его только тем, кому он нужен для релиза. В отчёте о сборке оставляйте версию движка, идентификатор пакета, тип артефакта и хеш файла, но не пароль, alias с чувствительными данными или путь к защищённому хранилищу.

Последовательность сборки в Unreal Engine

Сверьте версию Unreal Engine и установленный Android toolchain с документацией Epic для этой версии.
Проверьте Android-параметры проекта: package name, SDK/API и целевую конфигурацию.
Поместите согласованный keystore в расположение, указанное документацией проекта и Epic, не добавляя его в контроль версий.
В Distribution Signing укажите имя keystore, alias и параметры доступа из защищённого источника.
Соберите тестовый артефакт для выбранного канала, сохранив журнал без секретов.
Проверьте установку и запуск на предусмотренном устройстве, затем отдельно выполните проверку требований площадки.

Если один из шагов не проходит, не начинайте с удаления случайных файлов из проекта. Сначала определите класс ошибки: не найден toolchain, неверный путь к keystore, ошибка alias, несовместимый формат, конфликт package name или требование площадки. Повторите минимальную сборку после одной корректировки. Это сохраняет причинно-следственную связь и облегчает передачу проблемы разработчику.

Проверка артефакта до распространения

Успешный пакетинг не равен готовности VR-приложения к выпуску. Минимальная проверка включает установку именно собранного артефакта, запуск на целевом устройстве, проверку версии и package name, а также доступ к ключевому сценарию приложения. Для Quest отдельно убедитесь, что используемый способ распространения и список поддерживаемых устройств соответствуют плану релиза. Не заявляйте, что сборка совместима со всеми Android-устройствами или всеми гарнитурами: это определяется приложением, runtime и политикой конкретной платформы.

Проверьте обновление поверх предыдущего тестового выпуска только в контролируемой среде. Если система сообщает о конфликте подписи, не обходите его сменой package name без решения владельца продукта: это создаёт другой пакет и меняет путь обновления. Документируйте, какой ключ и какая версия используются в ветке релиза, но не включайте секретные значения в документацию.

Типичные границы ответственности

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

Если проект использует плагины, при обновлении Unreal Engine перепроверьте их Android-настройки и лицензии. Не переносите бинарные плагины между несовместимыми версиями движка, не прочитав их документацию. Сборка должна быть воспроизводимой: другой член команды с разрешённым доступом к секретам и той же задокументированной средой должен получить тот же тип артефакта без ручного поиска неизвестных файлов.

Чек-лист перед релизом

Зафиксированы версия Unreal Engine, Android toolchain и канал доставки.
Проверены package name, версия приложения и требуемый формат APK/AAB.
Keystore, alias и пароли доступны по защищённой процедуре и отсутствуют в репозитории.
Собранный артефакт протестирован на целевом устройстве.
Логи и отчёты очищены от секретов.
Требования магазина или платформы проверены отдельно от локальной установки.

После крупного обновления движка повторяйте весь путь на тестовом выпуске. Порядок пунктов и названия настроек могут меняться, поэтому окончательным источником для конкретной версии остаётся актуальная документация Unreal Engine, Android и выбранной площадки.

Как организовать воспроизводимую среду

Подготовьте короткий документ сборки, где указаны версия Unreal Engine, версия проекта, используемый Android toolchain, нужные плагины, идентификатор пакета, тип артефакта и канал доставки. Отдельно храните инструкции по получению секретов: документ должен объяснять, кто вправе запросить доступ, но не содержать сам keystore или пароли. Такая граница даёт возможность повторить выпуск без превращения репозитория в хранилище ключей.

Перед сменой версии Unreal Engine соберите известный тестовый вариант в старой среде, затем повторите сборку в новой. Сравните не только факт завершения package, но и установку, запуск, версию пакета и ключевой сценарий на целевом устройстве. Если результат отличается, фиксируйте версию и один изменённый слой: движок, Android toolchain, плагин или настройки проекта. Нельзя уверенно объяснить ошибку, когда вся среда была обновлена одновременно.

Ошибки, которые не стоит маскировать

Сообщение о неподходящей подписи, отсутствии keystore или alias требует проверки конфигурации подписи, а не случайной пересборки. Ошибка установки может относиться к формату, package name, версии ОС либо конфликту с уже установленной версией. Ошибка запуска после установки может быть связана с разрешениями, нативными библиотеками, графическим API, ресурсами или VR-runtime. Разделение этапов, создание подписи, упаковка, установка, старт, экономит время и не приводит к ложным советам.

Не удаляйте ключ или релизные настройки, чтобы «начать с нуля», пока владелец продукта не подтвердит последствия. Для теста можно использовать отдельную контролируемую конфигурацию, но она не должна незаметно заменить подпись существующего выпуска. Если меняется package name, это отдельное приложение для Android и отдельный объект учёта на площадке.

Проверка для VR-проекта

Для VR-сборки дополнительно проверьте, что тест проводится на предусмотренной гарнитуре и через запланированный канал распространения. Пакет, который устанавливается на одном Android-устройстве, не доказывает работу на другой модели или в другом runtime. Совместимость зависит от настроек приложения, версии ОС, графического API, разрешений и требований платформы. Не объединяйте эту проверку с подписью: цифровая подпись решает задачу доверия к пакету, но не тестирует пользовательский сценарий.

После теста сохраните сведения об артефакте: имя, версию, дату, тип, хеш и результат проверки. Если выпуск отклонён площадкой, сохраните формулировку причины без секретов и сверьте её с документацией именно этой площадки. Это позволяет исправить конкретное требование вместо изменения случайных Android-настроек.

Перед передачей в релиз ещё раз проверьте, что тестовый и релизный ключи не перепутаны, а версия пакета согласована с планом обновления. Одно такое контрольное действие предотвращает конфликт, который затем ошибочно списывают на Unreal Engine или Android.