Android-приложение не проходит проверку Google Play: что исправить

Фраза приложение не прошло проверку объединяет разные случаи: техническую ошибку сборки, недоступный экран, несоответствие карточки, декларации данных, разрешений, подписок или правил контента. Исправлять всё сразу неэффективно — сначала нужен точный policy name, версия и шаги ревьюера.

Откройте уведомление и раздел состояния правил в Play Console, сохраните идентификатор нарушения, скриншоты, затронутую версию и срок ответа. Проверьте именно загруженный Android App Bundle из внутреннего тестирования, а не локальную debug-сборку.

Что проверить в первую очередь

Для проблемы «Android-приложение отклонено при проверке Google Play» сначала зафиксируйте один воспроизводимый пример: точное время, идентификатор объекта, пользователя или операции, входные данные, версию приложения и фактический результат. Отдельно запишите ожидаемое поведение: конкретное нарушение воспроизводится на той же версии сборки, исправление подтверждено документами и тестом, а новая отправка содержит точное объяснение изменений. Это не формальность. Без исходной точки легко принять временное совпадение за исправление, изменить сразу несколько условий и потерять возможность доказать настоящую причину сбоя.

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

• Сопоставьте versionCode отклонённой сборки с исходным кодом и артефактом.
• Проверьте доступ ревьюера: логин, регион, одноразовые коды и платные экраны.
• Сверьте Data safety и privacy policy с реальным поведением SDK.
• Просмотрите запрашиваемые permissions и их фактическую необходимость.
• Проверьте название, описание, скриншоты, возрастной рейтинг и рекламные заявления.

Почему возникает проблема

Видимый симптом обычно находится в конце цепочки. Пользователь видит неверный статус или отказ, хотя первичная ошибка могла произойти в API, фоновой задаче, кеше, очереди, внешнем сервисе либо при проверке доступа. Основной риск этого сценария: повторная отправка без устранения причины увеличивает срок публикации и может привести к ограничениям аккаунта разработчика. Поэтому исправление только интерфейса или ручная правка итоговой записи часто скрывает проблему, но не устраняет её.

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

• Инструкция для ревьюера не позволяет попасть в закрытую функцию.
• Сторонний SDK собирает данные, не отражённые в декларации.
• Чувствительное разрешение запрашивается при старте без контекстного объяснения.
• Карточка обещает функцию, которая недоступна в текущей сборке или регионе.
• Релиз подписан и настроен иначе, чем протестированный debug-вариант.

Пошаговая диагностика

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

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

• Установите точный bundle через internal testing на чистое устройство.
• Просмотрите merged manifest и список SDK релизной сборки.
• Пройдите сценарий ревьюера на поддерживаемых версиях Android.
• Проверьте сетевые обращения и сбор данных до согласия пользователя.
• Сопоставьте текст уведомления с текущим разделом официальной политики перед изменениями.

Как организовать исправление отклонённой сборки

Каждое отклонение оформляется как проверяемая задача: правило, доказательство, затронутый сценарий, изменение, тест и точный комментарий для следующей проверки. Политики нужно сверять в актуальной Play Console на дату отправки.

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

• Release artifact воспроизводимо собирается и имеет сохранённый mapping исходников.
• Декларация данных формируется из инвентаризации приложения и сторонних SDK.
• Чувствительные permissions запрашиваются только в момент понятной функции.
• Reviewer access регулярно проверяется отдельным тестом.
• Store listing описывает реально доступное поведение без вводящих в заблуждение обещаний.

Как исправить проблему

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

Если затронуты существующие записи, сначала сформируйте dry-run: список объектов, старое значение, предлагаемое новое значение и основание для изменения. Обновление должно быть идемпотентным, ограниченным точной выборкой и сопровождаться аудитом. Для финансовых данных, прав доступа и персональной информации предпочтительны компенсирующие записи, а не переписывание истории.

• Устраните именно указанное нарушение в минимальном патче.
• Удалите ненужные permissions и SDK или обновите декларацию по фактическому сбору данных.
• Подготовьте стабильный тестовый аккаунт и пошаговые инструкции без персональных данных.
• Обновите privacy policy, карточку и экран согласия, если поведение изменилось.
• В комментарии ревьюеру укажите versionCode, экран и способ проверить исправление.

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

• Сохраните конфигурацию, связанные записи и необходимые журналы; отдельно проверьте, что резервную копию действительно можно восстановить.
• Воспроизведите проблему на тестовом объекте и сохраните результат до изменения, чтобы после выпуска сравнить одинаковые сценарии.
• Внесите минимальное изменение под системой контроля версий, опишите причину, ожидаемый эффект, ограничения и точный способ отката.
• Прогоните нормальный сценарий, ошибочный ввод, повтор одного запроса, два параллельных запроса и временную недоступность зависимости.
• Выпустите изменение на ограниченную долю трафика или один процесс, если архитектура это позволяет, и сравните метрики со старой версией.
• Только после стабильного наблюдения выполните контролируемое исправление исторических данных и сохраните итоговый отчёт.

Как проверить результат

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

Критерии приёмки сформулируйте до выпуска. Каждый пункт должен давать однозначный ответ «выполнено» или «не выполнено», а не субъективную оценку. Если тест невозможно повторить автоматически, оставьте короткий регрессионный чек-лист с тестовыми данными и ожидаемыми статусами.

• Чистая установка релизного bundle проходит критический путь.
• Ревьюер входит по инструкции без привязки к личному телефону разработчика.
• Отказ от разрешения не приводит к падению и оставляет понятную альтернативу.
• Data safety соответствует каждому сетевому SDK и типу данных.
• Покупки, подписки и удаление аккаунта работают по заявленной схеме.

Типичные ошибки при исправлении

• Отправлять ту же сборку повторно только с новым описанием.
• Удалять видимый экран, оставляя запрещённое поведение в другом маршруте.
• Проверять только debug APK вместо release AAB.
• Спорить с уведомлением без воспроизводимого доказательства и точной ссылки на правило.
• Добавлять постоянные тестовые пароли в публичное описание приложения.

Опаснее всего исправление, которое убирает заметный симптом ценой отключения проверки, ослабления прав или потери аудита. Такое изменение может сделать интерфейс «зелёным», но увеличить ущерб при следующем сбое. Если временный обход всё же необходим, ограничьте его срок, пользователей и область действия, добавьте мониторинг и заранее назначьте дату удаления.

Как предотвратить повторение

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

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

• Отклонения по типу политики и повторяемость одной причины.
• Успешность сценариев reviewer access перед отправкой.
• Изменения permissions и SDK между версиями.
• Падения и ANR релизной сборки на критическом пути.
• Срок от получения уведомления до подтверждённого исправления.

Что подготовить для технического разбора

• Короткое описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время возникновения, идентификатор тестового объекта и версии всех затронутых компонентов.
• Обезличенные фрагменты журналов до и после ошибки с единым correlation ID.
• Список последних изменений, результаты уже выполненных проверок и условия, при которых симптом исчезает.
• Безопасный доступ к тестовой среде либо минимальный пример, не содержащий паролей, токенов и персональных данных.

Частые вопросы

Можно ли сразу подать апелляцию?

Если решение ошибочно и есть доказательства, да; при реальном нарушении быстрее сначала исправить конкретную причину.

Почему локальная версия работает, а ревьюер видит ошибку?

Release-конфигурация, подпись, серверные флаги, регион и чистое устройство могут отличаться от среды разработчика.

Нужно ли проверять правила заново?

Да, требования и формы Play Console меняются, поэтому перед отправкой следует сверять актуальную официальную документацию.

Когда нужна помощь специалиста

Если приложение отклонено в Google Play, я могу разобрать уведомление, release bundle, manifest, SDK, Data safety и путь ревьюера, затем подготовить точечное исправление. Для оценки нужны текст решения, versionCode и безопасный доступ к тестовой сборке.