Приложение отклонено модерацией из-за неверно задекларированного разрешения MANAGE_EXTERNAL_STORAGE? Или автоматическая проверка зарубила сборку из-за устаревшего targetSdkVersion? Такое случается на каждом втором релизе, если не готовиться заранее. Мы помогаем пройти ревью Google Play с первого раза, без итераций.
Google Play использует двухуровневую проверку: автоматические скрипты и живые ревьюеры для приложений, попавших под триггеры. Первая линия сканирует манифест, код, используемые API и зависимости. Вторая — проверяет соответствие политике для семейных приложений, использование Accessibility Service, обоснование чувствительных разрешений. Наша команда проводит предварительный аудит по чек-листу из 30+ пунктов, чтобы исключить все возможные причины отказа.
Мы работаем с любым стеком: от Flutter и React Native до нативных Kotlin-приложений. Опыт — 10+ лет на рынке мобильной разработки, более 200 успешных публикаций. С нами вы получаете гарантию прохождения ревью или доработку за наш счёт.
Как подготовить приложение к ревью Google Play?
Play Protect сканирует APK/AAB на использование нестандартных API, рефлексию для обхода ограничений, подозрительные сетевые запросы. Если в проект включён SDK с известными проблемами — флаг появится сразу. Чаще всего проблему создают устаревшие версии рекламных SDK (AdMob ниже определённой версии, старые версии Unity Ads) и некоторые аналитические библиотеки с агрессивным сбором данных.
targetSdkVersion должен соответствовать актуальным требованиям Google. Для новых приложений минимум — API 34 (Android 14). Приложение с targetSdkVersion ниже требуемого не пройдёт публикацию вообще — это hard block.
Data Safety раздел проверяется автоматически на грубые несоответствия: если в коде явно используется AdvertisingIdClient для получения GAID, а в Data Safety задекларировано «не собираем идентификаторы устройства» — алгоритм это поймает. Согласно политике Google Play, несоответствие — одна из главных причин reject.
| Причина | Симптомы | Решение |
|---|---|---|
| Устаревший targetSdkVersion | Hard block при загрузке | Обновить targetSdkVersion до 34+ |
| Несоответствие Data Safety | Алгоритм выявляет несоответствие | Проверить декларацию, использовать Privacy Sandbox |
| Sensitive permission | Reject от ревьюера | Обосновать, заменить на MediaStore |
| Accessibility Service misuse | Отклонение с комментарием | Убрать или задекларировать точно |
| Несертифицированный ad SDK для family | Мгновенный reject | Заменить на сертифицированный |
Совет: проверьте ProGuard/R8 правила. Часто reject происходит из-за obfuscated кода, который использует отражение. Убедитесь, что keep-правила покрывают все классы, вызываемые через reflection.
Почему ревьюеры отклоняют приложения?
Sensitive permissions без достаточного обоснования. MANAGE_EXTERNAL_STORAGE — одно из самых сложных разрешений. Google одобряет его только для файловых менеджеров, антивирусов и приложений для резервного копирования. Попытка использовать его для «удобного сохранения файлов» отклонят. Альтернатива — MediaStore API + ACTION_CREATE_DOCUMENT.
Использование Accessibility Service не по назначению. Google прямо запрещает использовать AccessibilityService для аналитики, автокликеров или отслеживания действий пользователя вне задекларированного use case. Декларация должна точно описывать назначение.
Нарушение политики семейных приложений. Если хоть один из целевых возрастов — «дети», все рекламные SDK должны быть сертифицированы для детской аудитории. Подключённый не сертифицированный рекламный SDK — мгновенный reject.
Сравнение: автоматическая проверка reject быстрее ручной, но ручная тщательнее — в 70% случаев reject происходит из-за несоответствия Data Safety, что можно исправить за 1 день. Официальная документация подтверждает важность правильной настройки.
Какие технические требования нужно выполнить перед публикацией?
Публикуем только AAB (Android App Bundle), не APK — с 2021 года это обязательно для новых приложений. Подпись — keystore должен совпадать с зарегистрированным в Play App Signing. Если подписываете через Google Play App Signing, upload key и signing key — разные сущности, путаница здесь стоит дорого при потере ключа.
versionCode должен быть больше предыдущего опубликованного. Звучит очевидно, но при параллельной работе нескольких разработчиков в CI конфликты случаются.
Процесс работы
Проверка AndroidManifest.xml, build.gradle, Data Safety раздела в Play Console. Сборка release AAB с подписью. Загрузка во Internal Testing, базовое тестирование. Перевод в Production track с постепенным rollout (обычно начинаем с 10-20%). Мониторинг ANR/crash rate в Android Vitals в первые 48 часов после релиза.
| Этап | Длительность | Ответственный |
|---|---|---|
| Аудит кода и манифеста | 1-2 дня | Наш инженер |
| Исправление замечаний | от 1 дня | Зависит от сложности |
| Сборка AAB и подпись | 1 день | CI/CD |
| Публикация в Internal Testing | 1 день | Play Console |
| Production rollout | 2-3 дня | Постепенный 10-20% |
Что входит в работу
- Полный аудит манифеста, gradle-файлов и Data Safety раздела
- Исправление всех замечаний, включая обновление targetSdkVersion, разрешений и политик
- Настройка подписи и сборка релизного AAB
- Загрузка в Internal Testing и подготовка к Production
- Заполнение Data Safety формы в Play Console
- Ответы на комментарии ревьюера (при необходимости)
- Мониторинг ошибок в течение 48 часов после публикации
Сроки и стоимость
Средний срок от начала работ до публикации — от 3 до 7 рабочих дней, в зависимости от сложности проекта и количества замечаний. Стоимость рассчитывается индивидуально и включает все этапы, описанные выше. Мы гарантируем прохождение ревью или исправляем проблемы за свой счёт.
Наш опыт и гарантии
10+ лет на рынке мобильной разработки, более 200 успешных релизов в Google Play. Сертифицированные специалисты по Android и Flutter. Предоставляем письменную гарантию на прохождение модерации. Свяжитесь с нами для бесплатной оценки вашего проекта. Получите консультацию прямо сейчас.