Google Play Console для первого приложения: пошаговый runbook

Проверено по официальной справке Google 1 сентября 2026 года; инструкция рассчитана на интерфейс конца августа 2026 года. Google выкатывает изменения интерфейса постепенно, поэтому название пункта иногда отличается у разных аккаунтов. В таком случае используйте поиск в верхней части Console и английское название из этой инструкции, затем сверяйте экран с указанной официальной ссылкой.

Это практическая инструкция, но не юридическая или налоговая консультация и не гарантия одобрения. Сначала прочитайте справочник терминов.

Что в итоге делает каждый участник

Участник	Делает	Не передаёт другому
Владелец	Регистрирует developer account, оплачивает сбор, проходит проверку, подтверждает юридические и фактические ответы, решает выпускать ли приложение	Документы, пароль Google, коды 2FA, окончательную ответственность
Codex	Готовит проект, проверки, тексты-черновики, внешний signing, AAB и доказательства; указывает, что именно нажать	Не угадывает факты, не принимает соглашения, не загружает в Play без прямой просьбы
Google	Проверяет аккаунт, сборку, карточку и анкеты; подписывает пользовательские APK при Play App Signing	Не подтверждает, что ответы разработчика правдивы; за них отвечает владелец
Тестировщики	Добровольно присоединяются, реально используют приложение, сообщают о проблемах	Не должны передавать свой Google Account или изображать фиктивное использование

0. Подготовка до регистрации

Не начинайте регистрацию, пока не готовы следующие данные:

• отдельный Google Account владельца с двухэтапной аутентификацией;
• постоянные email разработчика и email поддержки;
• настоящее юридическое имя, страна и адрес;
• действующий цветной документ и подтверждение адреса;
• законный платёжный инструмент для разового сбора 25 USD; prepaid card Google не принимает, а работоспособность конкретной российской карты не гарантируется;
• выбранный тип аккаунта: Personal для физлица или Organization только для реально существующей организации/ИП;
• для Organization — официальные реквизиты, сайт, рабочие контакты и обычно D-U-N-S;
• для нового Personal — доступ к настоящему не-rooted Android 10+ телефону для device verification.

Важно для пользователя без физического телефона: локальную разработку и тесты можно закончить на AVD, но проверку устройства Play Console эмулятор не принимает. Телефон можно подготовить позже; он должен быть доверенным и использоваться владельцем при входе в мобильное приложение Play Console. Не передавайте пароль Google владельцу чужого устройства.

Для российского профиля ФИО и адрес в документах должны точно совпасть с Google Payments profile. Используйте чёткий цветной оригинал без редактирования и не указывайте фиктивную страну. Подробности: отдельная инструкция для гражданина РФ.

1. Зарегистрировать Play Console

1. Войдите нужным Google Account на странице регистрации Play Console.
2. Примите Google Play Developer Distribution Agreement только после чтения.
3. Выберите Personal либо Organization. Не выбирайте Organization ради обхода тестирования: данные организации будут проверяться.
4. Создайте или выберите Payments profile с настоящими данными.
5. Оплатите разовый регистрационный сбор 25 USD. Сохраните письмо и квитанцию в защищённом архиве владельца.
6. Заполните имя разработчика, контактный email/телефон и публичный developer email. Публичные поля будут видны пользователям.
7. Откройте Developer account > About you и завершите все карточки со статусом Action required.
8. Подтвердите email и телефон шестизначными кодами. Телефон вводите в международном формате.
9. Пройдите identity verification в порядке, который показывает Console. Не обрезайте документ так, чтобы исчезли края или обязательные поля.
10. Если Personal-аккаунт показывает задачу проверки устройства: на главной странице нажмите View details, откройте QR-код; на физическом Android 10+ установите официальное приложение Google Play Console, войдите аккаунтом владельца, откройте Account > Verify и отсканируйте QR.

Если проверка отклонена, не загружайте подряд разные варианты. Сначала сравните каждый символ имени/адреса с Payments profile, качество и тип документа. Затем используйте ссылку support из карточки проверки и сохраняйте номера обращений.

Официальные основы: регистрация и оплата, данные аккаунта, проверка контактов и личности, проверка устройства.

2. Создать карточку приложения

До нажатия кнопки окончательно выберите Package ID: для Arcade это ru.gulaev.arcade. После первой публикации его нельзя переименовать.

1. На главной странице Play Console нажмите Home > Create app.
2. Выберите основной язык. Для русской карточки можно выбрать Russian – ru-RU; английский перевод добавить позже.
3. Введите название приложения: максимум 30 символов.
4. Выберите App или Game. Для Arcade — Game.
5. Выберите Free или Paid только после решения о бизнес-модели. Для текущего Arcade без Play Billing — Free.
6. Укажите рабочий email поддержки.
7. Подтвердите обязательные декларации и участие в Play App Signing только после чтения текста на экране.
8. Нажмите Create app.

После создания используйте страницу Dashboard как список обязательных задач. Красный статус или Needs attention означает, что публикация заблокирована. Официальная последовательность создания.

3. Заполнить Store listing

Store listing открывается через Grow users > Store presence > Main store listing. В некоторых вариантах навигации сначала виден пункт Store listings.

Заполните:

• App name — до 30 символов;
• Short description — до 80 символов;
• Full description — до 4000 символов;
• App icon — PNG 512×512, до 1024 KB;
• Feature graphic — обязательное изображение 1024×500;
• не менее двух скриншотов; допустим JPEG или 24-bit PNG, каждая сторона 320–3840 px, длинная сторона не более чем вдвое длиннее короткой;
• support email; сайт и телефон — если применимы.

Скриншоты делайте из проверенного release candidate, а не из макета. Не пишите «№1», «лучшее», цену, скидку, рейтинг или функции, которых нет. Не используйте чужие товарные знаки, изображения и названия. Категория и теги задаются в Grow users > Store presence > Store settings.

Перед сохранением сравните каждое обещание с реальным приложением. Требования к графике: официальная справка Store assets.

4. Заполнить App content

Откройте Policy and programs > App content. В некоторых аккаунтах путь сокращён до Policy > App content. Каждая карточка должна получить статус завершённой. App content — не формальность: владелец подтверждает факты и несёт ответственность за ответы.

Рекомендуемый порядок:

1. Privacy policy. Вставьте публичный HTTPS URL политики конфиденциальности. Страница должна открываться без входа, совпадать с текущим приложением и иметь контакт. Черновик в репозитории сам по себе не является публичным URL.
2. Ads > Start/Manage. Ответьте, содержит ли приложение рекламу. Для текущего Arcade без рекламных библиотек предварительный ответ — No, но владелец подтверждает его по итоговому списку зависимостей. См. Ads declaration.
3. App access > Start/Manage. Если все функции открыты без логина и других ограничений, выберите эквивалент All functionality is available without special access. Иначе дайте проверяющему рабочий логин и точные шаги. Это App access, а не обращение в support.
4. Target audience and content > Start/Manage. Выберите только реальные возрастные группы. Для простой arcade-игры нельзя автоматически ставить «для детей» или «не для детей»: решение зависит от дизайна, текста, персонажей и маркетинга. Выбор детской аудитории включает дополнительные Families requirements. См. Target audience.
5. Content rating > Start questionnaire. Укажите email, выберите категорию Game и честно ответьте про насилие, страх, азартные механики, общение, покупки и пользовательский контент. Полученный IARC-рейтинг обновляют при изменении содержимого.
6. Data safety > Start. Сверьте код, серверы и каждый SDK. Укажите сбор, передачу, цели, обязательность, шифрование и удаление каждого типа данных. Текущий Arcade без сети и сторонних SDK может иметь ответ «данные не собираются и не передаются», но только после финального технического аудита. Ответственность за Data Safety остаётся у владельца.
7. News apps, Government apps, специальные разрешения, health/finance и другие появившиеся карточки заполняйте по фактической функции. Для Arcade ожидается не news и не government, но ответ подтверждает владелец.
8. Если приложение создаёт пользовательский аккаунт, отдельно настройте URL и in-app способ удаления аккаунта. Для Arcade без аккаунтов это неприменимо.

Сохраняйте датированную копию ответов в docs/play/, но не помещайте туда документы, пароли и данные тестировщиков. Официальные источники: подготовка к review, Data Safety, IARC, аудитория.

5. Страны, цена и публикация по времени

Откройте Test and release > Production > Countries/regions и нажмите Add countries/regions. Выбирайте только территории, где приложение, privacy/support и права на контент действительно готовы. Официально: доступность по странам.

До отправки включите Managed publishing: Publishing overview > Turn on managed publishing > Save. Тогда одобренные изменения будут ждать ручной команды. Это не ускоряет review, но не даёт приложению выйти в неудобный момент.

Google рекомендует закладывать минимум неделю на проверку, иногда больше. Не назначайте рекламу, пресс-релиз или обещанную дату до фактического одобрения. Официальная справка Managed publishing.

6. Подпись: два разных ключа

Upload key хранится у владельца и подписывает загружаемый AAB. App signing key хранит Google и подписывает APK, которые получают пользователи. Это разные роли.

В текущем интерфейсе сведения о ключах ищите одним из путей:

• Test and release > App integrity;
• Protected with Play > Play Store protection > Manage Play app signing.

Обычный процесс:

1. Владелец создаёт внешний keystore и делает offline backup.
2. Codex собирает подписанный AAB, не читая и не печатая пароль.
3. При первой загрузке владелец принимает Play App Signing.
4. Console показывает сертификаты и fingerprints; закрытый ключ туда вручную не копируется.

Если upload key потерян или скомпрометирован, откройте Manage Play app signing > Upload key certificate > Request upload key reset. Не создавайте новый Package ID ради обхода штатного сброса. Официально: Play App Signing.

7. Первая загрузка во внутренний тест

Internal testing — первый канал для подписанного AAB; он поддерживает до 100 тестировщиков.

1. Откройте Test and release > Testing > Internal testing.
2. На вкладке Testers нажмите Create email list, назовите список и добавьте Google-аккаунты тестировщиков. CSV сохраняйте в UTF-8 без BOM.
3. На вкладке releases нажмите Create new release.
4. Выберите или подтвердите Play App Signing.
5. Перетащите подписанный AAB.
6. Проверьте распознанные Package ID, versionCode и versionName.
7. Добавьте краткие release notes: что проверять и что изменено.
8. Нажмите Next, устраните все errors и разберите каждый warning.
9. Нажмите кнопку начала rollout для Internal только после разрешения владельца.
10. На странице теста скопируйте opt-in link. Тестировщик должен открыть её своим добавленным Google Account и явно присоединиться. Появление ссылки и доступности версии иногда занимает несколько часов.

После обработки установите именно Play-delivered build из Google Play и повторите clean install, запуск без сети, основной сценарий, Back, background/resume и сохранение. Локальный APK не доказывает этот этап.

Официальные шаги: настройка тестов, создание release.

8. Closed testing и production access для нового Personal-аккаунта

Для Personal-аккаунтов, созданных после 13 ноября 2023 года, обычно действует gate: минимум 12 тестировщиков должны оставаться opted-in в Closed testing непрерывно не менее 14 дней. Точный статус показывает Dashboard конкретного аккаунта.

Практический безопасный план:

1. Пригласите 15–20 знакомых добровольцев, чтобы уход нескольких людей не опустил число ниже 12.
2. Объясните, какие данные видят Google и разработчик; не собирайте лишние персональные данные.
3. Дайте opt-in link и отдельно убедитесь, что каждый нажал присоединение.
4. На 1-й, 3-й, 7-й и 13-й день попросите пройти короткие реальные сценарии.
5. Ведите обезличенный журнал: дата, модель/Android, сценарий, результат, feedback, исправление. Email и имена храните отдельно и только при необходимости.
6. Не покупайте фиктивные установки и отзывы, не обменивайтесь паролями и не используйте фермы тестировщиков. Число без реального использования не даёт полезного ответа на production questionnaire и может выглядеть как abuse.
7. После выполнения gate откройте Dashboard > Apply for production.
8. Честно заполните разделы о проведённом closed test, приложении и готовности к production. Укажите конкретный feedback и изменения, а не общие фразы.

Production access — разрешение аккаунту публиковать приложение. Оно не заменяет review конкретной версии: после доступа Production release проходит собственную проверку. Open testing и Production могут быть закрыты до выдачи доступа.

Официально: требования Personal testing.

9. Первый Production release

Переходите к Production, только когда: локальные тесты и Play-delivered smoke пройдены, анкеты точны, pre-launch report разобран, policy status чист, production access выдан и владелец дал отдельное разрешение.

1. Откройте Test and release > Production.
2. Проверьте Countries/regions.
3. Нажмите Create new release или Promote release, если Console предлагает продвинуть проверенную версию.
4. Убедитесь, что выбран тот же проверенный AAB и SHA-256, а versionCode соответствует evidence.
5. Заполните release notes для каждой активной локали.
6. Нажмите Next и устраните errors; каждый warning должен иметь осознанное решение.
7. Проверьте Publishing overview и список изменений.
8. Владелец отдельно подтверждает отправку на review.
9. После одобрения Managed publishing удержит изменения до ручной публикации.

Важная ловушка: первый Production-релиз нельзя безопасно «проверить на 1%» как обычное обновление — он становится доступен всем пользователям в выбранных странах. Риск уменьшают Internal/Closed тест, ограниченный осмысленный список стран и Managed publishing. Для последующих обновлений используйте staged rollout и наблюдение.

Не отправляйте одну и ту же отклонённую сборку снова. Прочитайте точную причину, исправьте код, карточку и декларации во всех tracks, сохраните доказательства и только затем переотправляйте. Повторные нарушения повышают риск policy enforcement.

10. Что проверять после публикации

В первые часы и ежедневно первую неделю:

• установите публичную версию на чистое устройство и проверьте главную функцию;
• откройте Monitor and improve > Android vitals и следите за crash и ANR;
• проверьте Policy status, сообщения Inbox и email владельца;
• отвечайте на отзывы без спора и без раскрытия данных пользователя;
• при серьёзной регрессии остановите staged rollout обновления либо подготовьте исправление с новым versionCode;
• обновляйте privacy/Data Safety и скриншоты одновременно с изменением функций, SDK и данных.

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

11. API, service account и «где получить токен»

Для первой ручной публикации API и токен не нужны. Сначала один раз пройдите Console руками. Автоматизацию подключайте, когда процесс понятен и повторяется.

Для автоматизации используется Google Play Developer API:

1. В Google Cloud Console создайте отдельный Google Cloud project для release automation.
2. Откройте APIs & Services > Library, найдите Google Play Android Developer API и нажмите Enable.
3. Откройте IAM & Admin > Service Accounts > Create service account. Назовите учётную запись по назначению, например gitea-play-internal.
4. Не выдавайте ей общую роль Owner/Editor в Cloud, если конкретный инструмент этого не требует.
5. Скопируйте только email нового service account.
6. В Play Console откройте Users and permissions > Invite new users, вставьте этот email и выдайте права только на нужное приложение и действие. Для загрузки в Internal не выдавайте Production rollout, финансовые данные и управление аккаунтом.
7. Google больше не требует отдельной операции «link project» между Play Console и Cloud: доступ определяется приглашённым email и permissions.
8. Если выбранный Gitea runner требует JSON credential, создавайте key только после отдельного security review: **Service Accounts > нужный account > Keys

   Add key > Create new key > JSON**. Сразу сохраните его как защищённый secret runner; не открывайте содержимое в Codex, не коммитьте и не отправляйте в чат.

9. Предпочитайте временные credentials без долгоживущего service account JSON key, если Gitea и выбранная инфраструктура это поддерживают.

Отдельный постоянный «токен Play Console» вручную не выдаётся. Клиент API по OAuth 2.0 получает короткоживущий access token из service account credential. Его не копируют в документацию и не запрашивают у пользователя в чате.

Официально: начало работы с Android Publisher API, права Play Console.

12. Практический журнал доказательств

Для каждого релиза сохраните без секретов:

Приложение / Package ID:
Версия / versionCode:
Дата и исходная revision:
SHA-256 подписанного AAB:
Команда полной проверки и результат:
AVD/устройства и Android API:
Основные сценарии и результат:
Play-delivered build проверен: да/нет
Pre-launch report: замечания / решения
Permissions и SDK изменились: да/нет, что именно
Privacy/Data Safety сверены с владельцем: дата
Store listing/screenshots сверены со сборкой: дата
Closed test: период, число opted-in, feedback, исправления
Policy status и Console warnings:
Решение владельца о submission/rollout:
Что осталось непроверенным:

Не записывайте сюда ключи, пароли, JSON credentials, документы, личные данные тестировщиков и reviewer credentials.

13. Уроки других начинающих разработчиков

Это не правила Google, а повторяющиеся наблюдения сообщества; интерфейс и решения review индивидуальны. Официальная документация выше имеет приоритет.

• Production access и review первого Production release — два разных решения; разрешение аккаунту не означает мгновенную публикацию сборки.
• Проверка документов часто ломается из-за несовпадения одного символа, транслитерации, обрезанного края или нечитаемого адреса. Лучше исправить источник несовпадения и открыть одно последовательное support case, чем загружать случайные варианты.
• В анкете production access полезны конкретные сценарии, feedback и сделанные изменения. «Всё хорошо» не показывает, что тест действительно проводился.
• Набор случайных платных тестировщиков создаёт privacy, abuse и quality риски; надёжнее небольшой круг реальных людей с понятным планом.
• После rejection нельзя менять только одно очевидное поле наугад: проверяйте код, все локализации карточки, активные tracks и декларации как единый набор.

Примеры обсуждений: production access и release review, опыт identity verification, опыт production questionnaire, повторные отклонения.

14. Короткое правило перед любой кнопкой Submit

Остановитесь и ответьте «да» на четыре вопроса:

1. Я понимаю, какой файл и какие изменения отправляю?
2. Все ответы описывают фактическую сборку, включая её SDK и серверы?
3. Секреты и личные документы не попали в проект, AAB, логи и screenshots?
4. Владелец явно разрешил именно submission или rollout на этом track?

Если хотя бы один ответ «нет» — не нажимайте Submit. Исправьте неопределённость и повторите чек-лист первой публикации.