Обжалование отклонения приложения в Google Play
Google Play отклоняет и снимает приложения по-другому, чем Apple: здесь больше автоматики, меньше диалога с ревьюером, и процедура апелляции строго формализована. Зато есть конкретные формы, policy strike appeal и возможность работать с Partner Support, если аккаунт Developer достаточно зрелый.
Понять тип отказа — первый шаг
Rejection при публикации — приложение не прошло pre-launch review. Play Console показывает конкретный policy violation. Это исправимо: устранить нарушение и переотправить.
Removal (снятие с публикации) — опубликованное приложение удалено из каталога. Причины: жалобы пользователей, автоматическая проверка обнаружила нарушение после обновления политик, или аналитика выявила использование запрещённых API в рантайме. Снятие приложения — серьёзнее rejection, и апелляция здесь критичнее.
Developer account suspension — блокировка аккаунта. Все приложения снимаются. Апелляция возможна, но процесс долгий и не всегда успешный. Если аккаунт заблокировали — нужно действовать быстро, пока 180-дневное окно для appeal не закрылось.
Механизм апелляции
Апелляция подаётся через форму в Play Console: Policy > Policy status > Appeal. Форма требует:
- Конкретную политику, которую, по мнению Google, нарушили
- Объяснение, почему приложение политику не нарушает, или что было исправлено
- Дополнительные материалы: скриншоты, видео-демонстрация функционала
Google обещает ответить в течение 72 часов, но реально — от двух до десяти рабочих дней.
Что реально влияет на исход апелляции:
Конкретность. «Мы считаем, что наше приложение соответствует политике» — это не аргумент. «Мы используем Accessibility Service исключительно для функции X, которая задокументирована в [ссылка на документацию], и не используем его для Y, что явно запрещено пунктом политики Z» — это аргумент.
Доказательства исправления. Если нарушение было реальным — описать, что именно изменено, предоставить diff кода или описание технических изменений. Google не принимает обещания «мы исправим» — нужно показать что уже сделано в новой версии, загруженной в Internal Testing.
Ссылки на аналогичные приложения. Если аналогичный функционал есть в других опубликованных приложениях в Play Store — это не гарантия, но весомый аргумент для апелляции по субъективным нарушениям (например, спорный контент-рейтинг).
Специфические случаи
Deceptive Behavior (обман пользователей) — один из самых сложных. Google относит сюда и реальный обман, и просто «непрозрачное поведение»: скрытая платная подписка, неочевидные разрешения, маскировка под системные приложения. Апелляция требует технических доказательств прозрачности: скриншоты subscription flow с чётким disclosure, список всех запрашиваемых разрешений с обоснованием.
Financial Services Policy — финтех-приложения с нераскрытой информацией о лицензировании или скрытыми комиссиями снимают без предупреждения. Для апелляции нужны документы: лицензия регулятора, раскрытие комиссий, Terms of Service.
Malware/Unwanted Software — если Play Protect пометил приложение как потенциально вредоносное из-за стороннего SDK, апелляция идёт через Google Security отдельно от стандартного policy appeal. Нужно идентифицировать конкретный SDK, обновить или удалить его, предоставить информацию о пересборке.
Кейс из практики
Приложение для HR-аналитики сняли по «Sensitive Permissions» — использовало READ_CALL_LOG для анализа рабочей коммуникации. Апелляция прошла после того, как мы: 1) добавили явный onboarding с объяснением назначения разрешения, 2) показали, что данные не покидают корпоративный контур (логи на сервере клиента, не в облаке разработчика), 3) подготовили Declaration Form с детальным описанием use case. Апелляция заняла восемь рабочих дней.
Срок работы — три-семь рабочих дней на подготовку апелляции, плюс время рассмотрения Google.