Тема
Google Play policy preflight: как снизить риск отклонения и блокировки
Проверено по официальным материалам Google 1 сентября 2026 года.
Ни один checklist не гарантирует одобрение: решение принимает Google, policy меняется, а факты о бизнесе и данных знает владелец. Цель документа — не «обойти модерацию», а до загрузки найти типовые нарушения, из-за которых app отклоняют, удаляют или приостанавливают вместе с риском для developer account.
Правило нулевого риска
Не отправляйте release на review, если неизвестен хотя бы один факт:
- кто владеет контентом, брендом и developer account;
- зачем нужен каждый permission/API/SDK;
- какие данные собирает app и каждый SDK, куда они уходят и как удаляются;
- как reviewer проходит login, paywall, geo/device restriction и основной flow;
- какая аудитория и regulated category выбраны;
- соответствует ли store listing фактической проверенной сборке.
Не используйте новый package/account для обхода suspension/termination и не переотправляйте тот же нарушающий bundle. Сначала исправляются все нарушения во всех tracks; repeated rejections/removals и серьёзные нарушения повышают риск suspension и termination связанных accounts.
1. Product gate: приложению есть место в Play
- App устанавливается, запускается, не зависает и выполняет заявленную задачу.
- Это не статичный PDF/text-only shell, не пустая заготовка и не WebView чужого сайта.
- У приложения есть самостоятельная mobile value, а не только ссылка, affiliate traffic или набор рекламы.
- Серия apps не дублирует один и тот же content/UX с другой иконкой или темой.
- Нет копирования чужого content, trademark, icon, screenshots или имени.
- Контент, внешние ссылки, ads, UGC и SDK также подпадают под Play policy.
Если несколько небольших приложений почти одинаковы, объедините их в один полезный каталог. Google прямо относит highly similar apps и копирование без добавленной ценности к spam/repetitive content.
2. Технический baseline на 1 сентября 2026
| App type | New app / update target API |
|---|---|
| Phone, tablet, Android Auto | API 36 (Android 16)+ |
| Wear OS | API 35+ |
| Android Automotive OS | API 35+ |
| Android TV | API 34+ |
| Android XR | API 34+ |
Дополнительно:
- формат — AAB и Play App Signing для новой app;
- уникальный постоянный package ID и растущий
versionCode; - native code поддерживает требуемые 64-bit ABI и 16 KB memory page size;
- для targeting API 35+ проверен 16 KB gate; с 1 февраля 2027 года updates без поддержки 16 KB нельзя выпускать на 64-bit устройства;
- release manifest не содержит debug overrides, лишних exported components, unexpected permissions или cleartext traffic;
- dependencies/SDK не deprecated, не уязвимы и соответствуют SDK policy;
- каждый commercial SDK проверен по Play SDK Index, а предупреждения Console разобраны до submission;
- app проходит lint/tests и install/upgrade/device smoke.
Перед каждым релизом снова открывайте Target API requirements и technical quality requirements.
3. Privacy, данные и SDK
Privacy policy
Даже app без сбора данных должна иметь privacy policy для Data Safety. Policy:
- доступна по публичному активному HTTPS URL без login и geoblock;
- является обычной non-editable web page, не PDF и не shared editable doc;
- указана в Play Console и доступна внутри app;
- называет app либо ту же entity, что указана в store listing;
- описывает фактические данные, цели, sharing, security, retention и deletion;
- содержит рабочий privacy contact.
Data Safety
- Заполняется для closed/open/production; internal-only track имеет исключение.
- Учитывает app code и каждый third-party SDK, включая default collection.
- Описывает сумму data practices всех активных версий/регионов данного package.
- Обновляется вместе с кодом, SDK configuration и server behavior.
- «SDK provider сказал, что безопасно» не снимает ответственность с developer.
В репозитории ведите таблицу:
text
Data type → source/API/SDK → required/optional → purpose → on/off device
→ destination/third party → encryption → retention → deletion
→ Privacy policy → Data Safety answerProminent disclosure и consent
Если sensitive data access не очевиден пользователю или работает в background:
- Покажите in-app disclosure в нормальном flow до permission/consent request.
- Назовите конкретный data type, функцию, использование в background и sharing.
- Получите отдельное affirmative action; Back/Home/таймаут не являются consent.
- Дайте отказаться и обеспечьте graceful degradation.
- Только после этого вызывайте Android runtime permission dialog.
Privacy policy и Data Safety не заменяют этот экран.
Accounts и deletion
Если app позволяет создать аккаунт, пользователь должен иметь понятный способ запросить удаление аккаунта и связанных данных:
- внутри app;
- по внешнему web resource, указанному в Play Console;
- с честным описанием retained data и законных сроков хранения.
Заморозка или logout не заменяют deletion.
4. Permissions и sensitive APIs
Каждый permission должен реализовывать текущую user-facing функцию, описанную в listing. Запрашивайте его contextual и постепенно. Не запрашивайте доступ для future feature.
| Capability | Gate до реализации/релиза |
|---|---|
| Background location | Core feature, disclosure/consent до permission, declaration и review video |
| SMS / Call Log | Только policy-eligible core/default-handler сценарий и declaration |
MANAGE_EXTERNAL_STORAGE | Только essential file-management use case и access review; предпочесть picker/scoped storage |
| Photos/video | Предпочесть system Photo Picker; broad access только при постоянной core need |
QUERY_ALL_PACKAGES | Inventory напрямую связан с core purpose; нельзя для ads/analytics |
| Accessibility API | Узкий policy-compliant use, listing disclosure; не автоматизировать автономные действия и не обходить controls |
VpnService | VPN/core eligible category, listing disclosure, encrypted tunnel; не перенаправлять traffic для monetization |
| Exact alarm | USE_EXACT_ALARM только для alarm/timer/calendar core; иначе более узкая альтернатива |
| Full-screen intent | Core alarm или incoming call use case |
| Foreground service | Верный service type, user-visible ongoing task и Play declaration, если требуется |
| Camera/microphone/contacts | Contextual request, denial path, Data Safety и expected-purpose limit |
| Install packages | Только разрешённый user-initiated core flow; не self-update вне Play |
Source of truth: Permissions and APIs that Access Sensitive Information и permissions declaration.
5. Store listing и review access
- Title, icon, descriptions, screenshots и video точно показывают текущую app.
- Не писать «официальное», «№1», «лучшее», рейтинг, fake awards, скидку/цену или невозможную функцию без допустимого подтверждения.
- Не имитировать Android/system warnings, другое приложение, бренд или государственную организацию.
- Category/app type соответствуют primary purpose; category нельзя менять ради обхода quality thresholds.
- Все локализации проверяются так же, как default language.
- Screenshots сняты с фактической release candidate, а не с design mockup.
- Ads declaration точна; рекламный SDK считается advertising даже если ads включаются remote configuration или только для части пользователей.
- IARC, target audience, app access, privacy и Data Safety завершены.
Если flow закрыт login, membership, OTP, MFA, location или paywall, предоставьте reviewer рабочие credentials и пошаговые инструкции. Аккаунт не должен истекать, требовать личный телефон reviewer или блокироваться rate limit. Проверьте его непосредственно перед отправкой.
6. Условные policy gates
| Функция/category | Что требуется спроектировать заранее |
|---|---|
| Ads | Ads declaration, disruptive/deceptive ads review, Data Safety, content rating |
| Digital goods/subscription | Play Billing, ясная цена/terms, restore и простой online cancellation path |
| Physical goods/services | Допустимая внешняя payment модель; не маскировать digital goods |
| Children/mixed audience | Accurate age selection, Families policy, neutral age screen, certified ads SDK, child data restrictions |
| UGC/social/chat | Terms acceptance, prohibited content rules, ongoing moderation, in-app report/block and response process |
| Generative AI | Prevent restricted output, in-app report/flag, moderation/filter feedback loop |
| Health/medical | Health apps declaration, public privacy policy, data minimization, legal/regulatory review, no harmful/misleading claims |
| Finance/crypto/loans | Financial features declaration, regional licences/disclosures, no deceptive products |
| News/government | Category declaration, provenance/ownership and no false official affiliation |
| VPN/security | Eligible core purpose, special declaration/disclosure and technical audit |
| Gambling/contests | Country/product eligibility and separate policy/legal review before implementation |
При появлении любой строки Codex обязан открыть актуальный раздел Developer Program Policy и не полагаться только на этот конспект.
Anti-abuse без ложной безопасности
Play Integrity API имеет смысл для server-backed риска: fraud, abuse, paid entitlements, competitive integrity. Проверяйте verdict на backend, применяйте ступенчатую реакцию и оставляйте recovery path для легитимного пользователя. Не добавляйте Integrity в полностью offline app «для галочки» и не используйте один verdict как единственный механизм блокировки: это добавит SDK/data/review surface без продуктовой пользы.
7. Quality gate и Android vitals
До review:
- clean install, cold start и основной flow проходят на релевантных profiles;
- нет crash, freeze, ANR, broken links и пустых экранов;
- обработаны offline/timeout/server error/session expiration;
- upgrade сохраняет данные или имеет проверенную migration;
- battery/background/network используются соразмерно;
- accessibility, adaptive layout и большие fonts не ломают ключевой flow.
Текущие общие bad-behavior thresholds Google Play включают user-perceived crash rate 1.09%, user-perceived ANR 0.47% и excessive partial wake locks 5%. Есть также per-device thresholds и будущие requirements. Эти метрики влияют на discoverability, поэтому после публикации release gate продолжается через Android vitals.
8. Pre-submit procedure
- Зафиксировать source revision, package/version и SHA-256 AAB.
- Снять merged manifest и dependency/SDK inventory.
- Сравнить permissions, SDK и data map с предыдущим release.
- Выполнить project verify и device scenarios.
- Проверить privacy URL, reviewer account и account-deletion URL извне.
- Сверить listing/screenshots/release notes с release candidate.
- Завершить Play Console App content и устранить critical pre-review issues.
- Загрузить в internal, установить именно Play-delivered build и повторить smoke.
- Разобрать pre-launch report; для закрытого flow настроить credentials, Robo script/game loop, но помнить, что автоматический отчёт не покрывает всё.
- Только после evidence переводить в closed/production staged rollout.
9. Что делать при enforcement
Различайте:
- rejection — release не принят, standing обычно не страдает;
- removal — опубликованная app снята; несколько removals повышают риск;
- suspension — strike, app/package и listing теряются, multiple strikes могут привести к termination связанных accounts;
- warning — имеет deadline, после которого app снимут;
- limited visibility — app остаётся, но discoverability ограничена.
При письме Google:
- Остановить повторные submissions и сохранить сообщение/evidence.
- Прочитать указанную policy целиком и проверить другие возможные нарушения.
- Исправить code, listing, declarations и все активные tracks.
- Деактивировать non-compliant bundles во всех tracks, где они присутствуют.
- Resubmit только проверенный compliant version.
- Appeal подавать один раз, предметно и с доказательствами, если решение фактически ошибочно; не спорить без исправления реального нарушения.
Официальная процедура: rejections, removals and suspensions.
Финальный stop/go checklist
STOP
- [ ] Неизвестно, какие данные собирает хотя бы один SDK.
- [ ] Есть permission без текущей core feature и denial path.
- [ ] Listing обещает функцию, которой нет в tested build.
- [ ] Reviewer не может пройти login/paywall/geo restriction.
- [ ] Privacy/Data Safety/ads/audience/IARC расходятся с кодом.
- [ ] App является почти копией другого продукта или использует чужой бренд.
- [ ] Есть crash/ANR/broken core flow или не проверен upgrade.
- [ ] Активен старый non-compliant bundle в другом track.
Любой отмеченный STOP блокирует отправку.
GO только при evidence
- [ ] Product value и права подтверждены.
- [ ] Technical baseline и target API актуальны.
- [ ] Manifest/SDK/data inventory reviewed.
- [ ] Все conditional declarations и disclosures готовы.
- [ ] Store listing и reviewer access проверены.
- [ ] Signed AAB принят internal track и Play-delivered build smoke-tested.
- [ ] Владелец подтвердил юридические ответы и rollout.