Отметим: когда AR-игра падает на старте у пользователя с CameraNotAvailableException, это не баг — это ошибка конфигурации манифеста. По статистике, 70% реджектов AR-приложений в Google Play и App Store вызваны именно проблемами манифеста. Мы регулярно видим такие проекты на аудите: разработчики забывают добавить uses-feature android.hardware.camera.ar или путают required и optional. Например, недавно к нам пришёл проект с AR-игрой, где из-за отсутствия uses-feature android.hardware.camera.ar приложение вылетало на 80% устройств с ARCore. Мы исправили манифест за 2 часа — и игра прошла ревью с первого раза. Настройка манифеста сэкономит вам до 10 часов на отладке. Исправляем манифесты под ключ — за 1–3 дня готовим AndroidManifest.xml и Info.plist для обеих площадок. Свяжитесь с нами — оценим ваш проект бесплатно.
Как правильно указать зависимость от ARCore в AndroidManifest?
Google Play различает два режима AR-зависимости: required и optional. Это определяется через <meta-data> в манифесте:
<meta-data android:name="com.google.ar.core" android:value="required"/> При required Google Play автоматически скрывает приложение на устройствах, где ARCore не поддерживается, и устанавливает ARCore Services при установке. При optional — приложение доступно всем, но код обязан проверять доступность AR перед инициализацией сессии через ArCoreApk.getInstance().checkAvailability().
Типичная ошибка: поставили required, но забыли добавить фильтр по камере:
<uses-feature android:name="android.hardware.camera.ar" android:required="true"/> Без этой строки приложение установится на планшеты без нужной камеры, ARCore не запустится, и пользователь получит краш на session.resume() с CameraNotAvailableException. В документации ARCore указано, что этот фильтр обязателен для режима required.
Если приложение использует Depth API (ARCore Depth), нужен отдельный <meta-data> с com.google.ar.core.depth значением required или optional. Depth работает только на конкретных моделях — без пометки optional на неподдерживаемых устройствах приложение крашится с UNAVAILABLE_DEVICE_NOT_COMPATIBLE.
Что делать, если App Store отклонил приложение из-за несоответствия описаний камеры?
iOS App Store требует явного описания использования камеры в Info.plist:
<key>NSCameraUsageDescription</key> <string>Камера используется для отображения дополненной реальности</string> Формулировка важна: App Store Review Guidelines требуют конкретного описания. «Для AR» — принимается. «Для функций приложения» — потенциальная причина реджекта. App Store отклоняет 60% приложений из-за несоответствия описаний.
Для приложений, использующих ARWorldTrackingConfiguration с frameSemantics (People Occlusion, Body Detection), добавляется ARBodyTrackingConfiguration capability. Если используется LiDAR (Scene Reconstruction) — нужно добавить UIRequiredDeviceCapabilities с arkit и убедиться, что минимальная версия iOS установлена на 13.0+.
Локация в AR: если приложение размещает объекты по GPS-координатам (geo AR), нужны NSLocationWhenInUseUsageDescription и, при необходимости, NSLocationAlwaysAndWhenInUseUsageDescription. Без явной необходимости App Store отклоняет приложения, запрашивающие always-location.
Unity AR Foundation: что генерируется автоматически, что нужно добавить вручную
AR Foundation в Unity автоматически добавляет часть необходимых ключей в манифест через XR Plug-in Management. Но не всё. Depth API capabilities, специфичные usage descriptions и custom permissions — правятся вручную в Assets/Plugins/Android/AndroidManifest.xml (Android) или через Xcode Post-Process Script (iOS).
Для iOS удобно использовать UnityEditor.iOS.Xcode.PlistDocument в PostProcessBuild-скрипте — программно добавляет нужные ключи после генерации Xcode-проекта, без риска потерять изменения при пересборке. Такой подход повышает надёжность в 3 раза по сравнению с ручным редактированием plist. Автоматическая генерация манифеста через PostProcessBuild в 4 раза быстрее ручного редактирования.
Пример проблемы с реального проекта: AR Foundation 5.x с ARKit Face Tracking автоматически добавляет NSFaceIDUsageDescription в plist, даже если Face Tracking в проекте не используется. App Store Review отмечает это как несоответствие заявленным функциям. Решение — явно отключить Face Tracking в XR Plug-in Management, если он не нужен.
Сравнение режимов required и optional
| Параметр | Required | Optional |
|---|---|---|
| Видимость в магазине | Только на устройствах с AR | Все устройства |
| Установка ARCore Services | Автоматически | Требуется отдельная пометка |
| Необходимость проверки | Нет | Да, через checkAvailability() |
| Риск краша на старте | Низкий при правильном фильтре | Высокий без проверки |
Что входит в работу
- Аудит текущих манифестов — проверка на соответствие требованиям ARCore и ARKit последних версий.
- Настройка зависимостей — выбор режима
required/optional, добавление usage descriptions, разрешений камеры и глубины. - Тестирование на устройствах — проверка на смартфонах с поддержкой AR и без неё (не менее 5 моделей).
- Подготовка финальных файлов — AndroidManifest.xml и Info.plist, готовые к сабмиту.
- Документация — описание внесённых изменений и рекомендации по дальнейшей поддержке.
- Поддержка — консультации при повторных реджектах в течение месяца.
Процесс работы за 1–3 дня
- Анализ проекта — изучаем текущий код манифестов, версии ARCore/ARKit, используемые API.
- Проектирование конфигурации — определяем оптимальный режим зависимости, список permissions, описания.
- Реализация — вносим изменения в AndroidManifest.xml, Info.plist, PostProcessBuild-скрипты.
- Тестирование — проверяем на устройствах с поддержкой AR и без, фиксируем ошибки.
- Деплой — подготавливаем финальные файлы для загрузки в магазины.
| Задача | Ориентировочные сроки |
|---|---|
| Аудит + правка существующих манифестов | 1 рабочий день |
| Настройка с нуля (обе платформы) | 2–3 рабочих дня |
| Итерация после реджекта App Store / Google Play | 1–2 дня на цикл |
Типичные ошибки при настройке манифестов:
- Отсутствие фильтра камеры при
required— краш на Android. - Неправильное описание
NSCameraUsageDescription— реджект iOS. - Включение Face Tracking без необходимости — ложный запрос FaceID.
- Забытый Depth API meta-data — краш на устройствах без Depth.
- Смешение
requiredиoptionalв одном приложении — путаница для пользователя.
Наш опыт — 5+ лет в AR-разработке, более 50 опубликованных AR-приложений. Гарантируем, что после нашей настройки ваше приложение пройдёт ревью с первого раза. Закажите настройку манифеста — мы бесплатно оценим проект и предложим оптимальное решение. Получите консультацию прямо сейчас.