Публикация приложения в Google Play: актуальный checklist

Коротко: release contract вместо кнопки Publish

Релиз готов, когда три описания продукта совпадают. Первое находится в коде и AAB: permissions, SDK, endpoints, способы входа и оплаты. Второе — в Play Console: Data safety, App content, audience, advertising и category-specific declarations. Третье видит человек: карточку, screenshots, privacy policy, поддержку и доступный сценарий проверки. Расхождение между ними важнее красоты отдельного документа.

1. Аккаунт, владелец и verification

Начинайте не со сборки, а с издателя. Personal account предназначен для личных проектов, Organization — для организации или бизнеса; для некоторых категорий, включая финансовые, медицинские, государственные приложения и одобренные сценарии VPN, Google требует организационный тип. Для Organization обычно нужен D‑U‑N‑S. Состав подтверждаемых и публично показываемых данных зависит от типа аккаунта, monetization и региона, поэтому не переносите чужой список документов как универсальный.

Коммерческий продукт должен жить в аккаунте реального владельца. Owner email, recovery, двухэтапная проверка, payments profile и критичные соглашения не должны принадлежать студии или уволившемуся сотруднику. Подрядчиков добавляют как users с минимально достаточными account-level или app-level permissions, а пароль owner не передают. До старта сохраните реестр ролей, резервный способ восстановления и ответственных за policy notices. Формальный transfer существует, но имеет eligibility-проверки и ограничения; это не быстрый способ исправить изначально неверное владение.

Verification аккаунта подтверждает сведения издателя, но не означает, что конкретное приложение пройдёт review. И наоборот, рабочая тестовая сборка не компенсирует неподтверждённую личность или неактуальные контакты. В release evidence должны находиться тип и дата создания account, статус verification, доступ owner, список пользователей и подтверждение, что публичные контакты действительно принимают письма.

Для передачи проекта составьте короткий ownership pack. В него входят юридическое имя издателя, идентификатор developer account, владельцы платежного профиля и домена privacy policy, перечень выданных ролей, контакты восстановления и календарь проверки доступов. Отдельно укажите, кто может менять production, отвечать на сообщения Google и принимать риск остановки продаж. Секреты не вкладывают в документ: для них используют контролируемое хранилище, а в акте фиксируют только факт передачи и процедуру доступа. После завершения работ удалите лишние роли подрядчика, не ломая сервисные интеграции. Такой handoff уменьшает риск не только публикации, но и будущих обновлений, апелляций и срочного восстановления аккаунта.

2. AAB, package name и два ключа signing

Новые приложения публикуются через Android App Bundle. До первого upload согласуйте applicationId: package name уникален и постоянен, удалить его и затем использовать заново нельзя. Название на витрине меняется, идентичность пакета — нет. Не оставляйте в ней имя подрядчика или прототипа. Проверьте, что version code выше предыдущих, Release-конфигурация не содержит debug signing, тестовых серверов, скрытого меню и секретов.

В Play App Signing участвуют разные ключи. Команда подписывает загружаемый AAB с помощью upload key. Google управляет app signing key и подписывает оптимизированные APK для устройств. Смешивать эти сущности опасно: потеря upload key имеет отдельный recovery process, а fingerprints app signing certificate нужны внешним API, OAuth, Maps, App Links и другим интеграциям. Зафиксируйте владельца ключей, защищённую резервную копию, процедуру восстановления и fingerprints без публикации секретного материала.

После загрузки откройте App bundle explorer: проверьте manifest, delivery, поддерживаемые устройства, native libraries, permissions и размер. Обновление должно продолжать тот же package, versioning и signing lineage. Если release pipeline не воспроизводит артефакт из известного commit, сначала исправьте pipeline: ручной bundle с ноутбука плохо поддаётся расследованию и hotfix.

Полезный bundle preflight связывает технические проверки с продуктом. Сравните список экранов и модулей с dynamic feature delivery, убедитесь, что обязательная функция не попала в недоступный модуль, а поддерживаемые ABI и device catalog соответствуют аудитории. Проверьте network security config, release endpoint, feature flags, локализации и ресурсы высокой плотности. Затем установите созданный Play артефакт через тестовый трек, а не только локальный APK из среды разработки: способы сборки и доставки различаются. Результат оформите как запись «package — version code — commit — среда — дата — проверивший», чтобы support мог точно назвать проблемную версию, а разработка — повторить её без догадок.

3. Testing tracks и scoped production access

Internal testing подходит для быстрого smoke и ограничен выбранными тестировщиками; closed testing — для контролируемой группы; open testing открывает присоединение широкой аудитории; production распространяет приложение в выбранных странах. Internal track можно запустить раньше полного setup, но его обработка отличается и он не доказывает policy approval. Обратная связь тестировщиков не становится публичным рейтингом.

Отдельное правило действует не для всех. Для personal developer accounts, созданных после 13 ноября 2023 года, перед заявкой на production access конкретное приложение должно пройти closed test: минимум 12 тестировщиков, непрерывно opted-in не менее последних 14 дней, причём минимум 12 остаются подключёнными в момент заявки. После этого разработчик отвечает на вопросы о тесте, feedback и готовности. Выполненные числа дают право подать заявку, а не автоматический доступ к production и не гарантию публикации. Open или internal test не подменяют этот gate.

Сохраняйте evidence теста: cohort, даты opt-in, release, канал feedback, найденные проблемы, исправления и ответы production-readiness. Не просите людей просто числиться в списке. Google интересует, как тест повлиял на продукт, а команде нужны реальные наблюдения на разных устройствах, сетях и версиях Android.

Организуйте closed test как маленький управляемый релиз. Дайте участникам инструкцию по установке, список ключевых задач и канал, где можно сообщить модель устройства, версию Android и шаги воспроизведения. Не публикуйте персональные данные тестировщиков в общих таблицах. Еженедельно разбирайте feedback, присваивайте проблемам приоритет и связывайте исправление с новой сборкой. Непрерывность opt-in проверяйте заранее: поздняя замена участника может не сохранить требуемое окно. Перед заявкой сформулируйте, кто тестировал, какие сценарии прошли, что сломалось, что команда изменила и почему продукт готов к реальным пользователям. Эти ответы должны опираться на журнал, а не на рекламное описание.

4. Target API: текущий уровень и даты 2026 года

На дату этого материала, 30 июля 2026 года, стандартные новые mobile apps и updates должны target Android 15, API 35 или выше. С 31 августа 2026 года для них требуется Android 16, API 36 или выше. Google сообщает о возможности запросить extension до 1 ноября 2026 года, но не считайте продление автоматическим: доступность и условия проверяются в Console.

Для Wear OS и Android Automotive OS с 31 августа 2026 года действует API 35+, для Android TV и Android XR — API 34+. У существующих приложений есть отдельное правило доступности новым пользователям на устройствах с более новой ОС. Всегда открывайте строку своего form factor и сценария — new app, update или existing-app availability. targetSdk не равен minSdk: повышение target не обязано отрезать старые устройства, но активирует новые платформенные ограничения и требует regression.

После migration проверьте runtime permissions, уведомления, foreground/background execution, storage, media, deep links, edge-to-edge и поведение сторонних SDK. Формальное число в manifest не является доказательством совместимости. Если статья используется после 31 августа, текущую строку primary source нужно перечитать до отправки.

5. Data safety, permissions и App content

Data safety описывает не только данные, которые видит издатель. В аудит входят собственный код, backend и каждый SDK: аналитика, crash reporting, реклама, attribution, chat, maps, платежи и push. Для каждого поля данных определите источник, уходит ли оно с устройства, получателя, purpose, обязательность, retention/deletion и соответствующий текст privacy policy. Collection и sharing имеют определения Google; бытового смысла слова недостаточно.

Приложение на closed, open или production track заполняет Data safety и предоставляет privacy policy, даже если заявляет, что не собирает данные. Исключение есть для приложения, активного исключительно в internal testing, а также для отдельно названных Google system services и private apps. Проверка Google не переносит ответственность за точность формы с разработчика. Декларация относится к package глобально, поэтому локализации не должны противоречить ей.

Uploaded bundle определяет, какие permission declarations появятся. SMS, Call Log и другие sensitive/high-risk permissions требуют допустимого core use case и могут потребовать форму, видео, инструкции и credentials. Неиспользуемое разрешение лучше удалить из manifest и зависимостей, чем объяснять. Активный несоответствующий artifact в тестовом треке способен блокировать публикацию других изменений, пока permission или declaration не исправлены.

В App content проверьте privacy policy, app access, ads, content rating, target audience, health apps declaration и условные формы для финансовых, новостных, государственных, VPN и иных функций. Health declaration заполняют и приложения без health-функций. Единого вечного списка нет: dashboard строится по фактическому продукту, SDK, permissions, категории и monetization. Требования Android developer verification и package registration с датой действия 30 сентября 2026 года на дату среза являются будущими; перед публикацией после этой даты нужно заново проверить Console.

Практически аудит начинают с инвентаризации, а не с формы Console. Android-разработчик выгружает manifest и dependency tree, backend-команда перечисляет получателей и журналы, product owner описывает обязательные пользовательские поля, а privacy-ответственный сопоставляет это с политикой. Для каждого расхождения выбирают одно из трёх действий: убрать ненужный сбор, изменить интерфейс и consent либо обновить declaration и документ. Screenshots заполненных форм сохраняют вместе с версией AAB и датой проверки. При следующем релизе сравнивают только изменения, но полный аудит повторяют после замены аналитики, рекламы, авторизации, платежей или модели хранения. Так Data safety остаётся отражением системы, а не архивной анкетой первого запуска.

6. Карточка, поддержка и доступ проверяющего

Default store listing включает название до 30 символов, short description до 80 и full description до 4000. Иконка — 512×512 PNG в допустимом размере; требования к screenshots и graphics зависят от device type и меняются, поэтому перед производством assets сверяйте текущую страницу Preview assets. Карточка показывает реальный продукт: не обещает отсутствующие функции, не имитирует официальный статус, не набивает описание нерелевантными ключами и не использует запрещённые ranking, price или promotion claims.

Проверьте category, app/game type, локализации, страны и обязательный контактный email. Privacy и support URL должны открываться без корпоративного VPN, соответствовать издателю и давать рабочий способ связи. Скриншоты снимают с релизного поведения, а не с дизайна будущей версии. Если функция зависит от региона, подписки, роли или устройства, это честно отражают в metadata и reviewer instructions.

Закрытый login — зона частых сбоев проверки. Подготовьте активный demo account с наполненными данными и доступом ко всем проверяемым ролям. OTP не должен приходить на личный телефон сотрудника; QR, PIN, geo restriction, invite-only и аппаратная интеграция требуют воспроизводимой инструкции или допустимого демонстрационного пути. Проверьте credentials непосредственно перед отправкой и не удаляйте их, пока change находится на review. Notes должны быть короткими: стартовая точка, данные входа, шаги, ожидаемый результат и особые условия.

7. Pre-launch report, Android vitals и P0

Pre-launch report может автоматически прогнать AAB на наборе устройств и показать стабильность, совместимость с Android, производительность и доступность. Для закрытого приложения передают тестовые данные для входа или собственные тесты. Отчёт зависит от доступности лаборатории и покрытия автоматического обхода; он не гарантирует обнаружение всех дефектов и не заменяет QA. Разберите каждую релевантную находку, отметьте ложное срабатывание доказательством и повторите быструю проверку на физическом или облачном устройстве целевого профиля.

Минимальный P0-путь 13FOX: чистая установка и update; первый запуск; signup, login и recovery; основная транзакция; платеж и восстановление, если применимы; allow и deny для permissions; offline и плохая сеть; background, notification и deep link; удаление аккаунта, если он создаётся; privacy/support links; отсутствие crash в smoke. Это редакционный release gate, а не официальный универсальный список Google. Открытый дефект, затрагивающий деньги, данные, безопасность, вход или основную функцию, блокирует production.

Android vitals измеряет production-поведение. На дату среза bad-behavior threshold для user-perceived crash rate составляет 1,09% overall и 8% на модель телефона; для user-perceived ANR — 0,47% overall и 8% на модель. Google обычно рассматривает последние 28 дней, но может реагировать раньше на всплеск. Эти границы способны влиять на discoverability и предупреждения, однако не являются приемлемой внутренней целью качества: команда задаёт более строгие stop conditions по своему трафику и риску.

8. Review и enforcement: разные статусы

Не объединяйте все отрицательные исходы словом «бан». Rejection не публикует новую submission или update; прежняя compliant-версия существующего приложения может остаться доступной. Removal снимает опубликованное приложение до compliant update. Suspension удаляет приложение, влияет на standing и влечёт потерю пользователей, статистики и рейтингов для suspended app. Warning оставляет приложение до срока из notice. Limited visibility ограничивает обнаружение, но не равна removal. Account termination прекращает доступ к публикации и может затронуть связанные аккаунты.

После уведомления сохраните точный текст, policy clause, package, version code, track и evidence. Воспроизведите проблему, выберите исправление или аргументированную апелляцию и остановите бессмысленные повторные загрузки. Если действие кажется ошибочным, используйте формальный appeal route и отвечайте фактами: что делает версия, где это видно и какой документ подтверждает позицию. Не создавайте replacement account для обхода enforcement.

Managed publishing управляет моментом выхода уже одобренных changes, но недоступен для первой публикации. Он не ускоряет review и не превращает проверку в SLA. Google описывает ориентиры обработки, однако срок может быть больше; поэтому нельзя обещать клиенту «24–48 часов», «ровно семь дней» или approval к дате кампании. Планируйте буфер и зависимые коммуникации так, чтобы неопределённость магазина не ломала бизнес-запуск.

9. Rollout, мониторинг и остановка

Staged rollout работает для обновлений, а не для первой публикации. Процент можно увеличивать, останавливать и возобновлять; пользователи выбираются системой, могут оставлять публичные отзывы, а достижение заданной группы занимает время. Halt ограничивает дальнейшее распространение, но не удаляет версию у уже выбранной cohort. Поэтому staged rollout дополняют feature flags, совместимым backend и планом hotfix.

До старта назначьте release manager и владельцев сигналов. Наблюдайте user-perceived crashes и ANR, кластеры по моделям, login/payment/core-transaction failures, backend errors и latency, отзывы, поддержку, Data safety или permission mismatch. Stop conditions задаются заранее: кто останавливает rollout, при каком сигнале, как отключается рискованная функция и кто сообщает пользователям. Порог Google — внешняя граница качества экосистемы, а не момент, когда бизнесу наконец следует реагировать.

После первого выхода проверьте страницу и установку из каждого ключевого региона, новую регистрацию, deep links, push, платежи, support и серверные события. После обновления сравнивайте cohort с baseline и не повышайте процент только по календарю. Изменения SDK, permissions, data flow, audience или monetization требуют обновить release evidence и декларации до следующей отправки.

Incident runbook должен быть написан до инцидента. В нём укажите ссылку на dashboard, владельца решения, допустимые действия в Console, порядок halt, feature flag и серверного rollback, шаблон сообщения support и критерий возобновления. Для каждого сигнала нужна проверка знаменателя: десять ошибок могут быть катастрофой при двадцати попытках и шумом при миллионе. Сегментируйте данные по version code, модели, Android, стране, новому и обновившемуся пользователю. После остановки не возобновляйте rollout только потому, что график успокоился: подтвердите исправление на той же конфигурации, выпустите проверенный artifact и наблюдайте ограниченную cohort. Итоги занесите в post-release review, чтобы следующий checklist учитывал реальный отказ.

First-party границы: что является источником

Источник требований — актуальные Google Play Console Help, Developer Program Policies, Android Developers и сообщения в Console по конкретному account/package. Эта статья, материалы агентств, форумы и видео помогают организовать процесс, но не создают исключений. Live dashboard имеет приоритет для форм, которые появляются по manifest, категории и региону. Юридические вопросы о privacy, правах и публичных данных требуют оценки в применимой юрисдикции.

Датированные факты особенно быстро стареют. Перед отправкой перепроверьте target API, scoped testing для новых personal accounts, package registration с 30 сентября 2026 года, Android vitals, App content и текущий appeal route. Не переносите правила App Store на Google Play и наоборот. Мы не обещаем фиксированный срок review, отсутствие дополнительных запросов или одобрение — решение и применение policy остаются за Google.

Когда отдельная услуга публикации не нужна

Не заказывайте сопровождение только ради кнопки, если account уже verified и принадлежит бизнесу, pipeline воспроизводим, package/signing документированы, команда ведёт инвентаризацию SDK, сама обновляет Data safety и declarations, готовит reviewer access, проводит P0 и дежурит после выхода. Для малорискового update опубликованного приложения без изменений данных, permissions и metadata часто достаточно внутреннего delta preflight и staged rollout.

Услуга преждевременна, если продукт не готов: основная функция падает, backend нестабилен, права на контент не подтверждены, data flows неизвестны или бизнес не выбрал издателя. Специалист по публикации не исправит это настройкой Console. Сначала устраните продуктовый или организационный блокер. Если нужен общий контроль качества, используйте чек-лист приложения перед релизом; если релиз ведёт опытная внутренняя команда, не создавайте лишний внешний доступ.

Официальные источники и дата проверки

Платформенные сведения проверены 30 июля 2026 года. Перед каждой отправкой сверяйте первоисточники и сообщения Play Console для конкретного приложения.

• Google Play: testing requirements for new personal accounts.
• Google Play: target API level requirements.
• Android Developers: app signing.
• Google Play: Data safety.
• Google Play: Android vitals.
• Google Play: enforcement outcomes.
• Google Play: staged rollouts.

FAQ

Можно ли гарантировать публикацию приложения в Google Play?

Нет. Решение принимает Google, а проверка может выявить дополнительные вопросы к аккаунту, сборке, декларациям или продукту. Checklist снижает риск и делает отправку воспроизводимой, но не гарантирует одобрение или дату публикации.

Всем ли нужны 12 тестировщиков на 14 дней?

Нет. На 30 июля 2026 года это требование относится к personal developer accounts, созданным после 13 ноября 2023 года. Для заявки на production access нужны минимум 12 непрерывно подключённых тестировщиков в closed test не менее последних 14 дней; затем Google отдельно оценивает заявку.

Можно ли опубликовать новое приложение в формате APK?

Для новых приложений Google Play требует Android App Bundle. Разработчик подписывает загружаемый AAB upload key, а Google в Play App Signing управляет app signing key и подписывает APK, создаваемые для конкретных устройств.

Нужны ли Data safety и privacy policy, если приложение не собирает данные?

Да, для приложения на closed, open или production track форму Data safety и privacy policy готовят даже при заявлении об отсутствии сбора данных. Нужно учесть поведение сторонних SDK. Отдельное исключение действует для приложения, активного только в internal testing, а также для некоторых названных Google категорий.

Что делать после rejection или suspension?

Сначала прочитайте точный статус и уведомление: rejection, removal и suspension имеют разные последствия. Зафиксируйте policy clause, версию и доказательства, устраните подтверждённое нарушение или подайте содержательную апелляцию, если решение ошибочно. Не отправляйте дубликаты вслепую и не создавайте новый аккаунт в обход enforcement.

Когда услуга публикации в Google Play не нужна?

Отдельное сопровождение не нужно, если аккаунт подтверждён и принадлежит бизнесу, команда поддерживает release pipeline, сама сверяет SDK и декларации, готовит карточку и reviewer access, проводит P0 QA и дежурит на rollout. Для простого обновления часто достаточно внутреннего delta preflight.

Проверим релизный контур до production

Пришлите тип и дату создания account, package name, список SDK и permissions, AAB, черновики Data safety и карточки, тестовый сценарий и страны запуска. 13FOX соберёт карту блокеров по владению, signing, testing eligibility, target API, declarations, reviewer access и P0, отделит обязательные исправления от рекомендаций и подготовит rollout plan. Решение и сроки остаются за Google; наша задача — сделать отправку согласованной, проверяемой и управляемой.

Разобрать публикацию