Требования Google Play в 2026 году: чек-лист перед публикацией

Сначала проверьте аккаунт и календарь выпуска

Самые неприятные проблемы с Google Play не всегда похожи на серьёзное нарушение. Сборка готова, скриншоты согласованы, и вдруг выясняется, что ответ в разделе «Безопасность данных» не совпадает с работой библиотеки аналитики, а проверяющий не может получить одноразовый код. Маленькая несостыковка возвращает к работе сразу разработчиков, юриста и маркетолога.

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

Этот материал проверен 8 сентября 2026 года. Google регулярно обновляет правила и сроки, поэтому перед каждой отправкой открывайте страницы, указанные в конце статьи. Сам подход от дат не зависит: зафиксируйте, что в действительности делает конкретная сборка, а затем приведите все формы и публичные обещания в соответствие с ней.

До работы над скриншотами убедитесь, что аккаунт вообще получил доступ к публикации.

Для новых личных аккаунтов разработчика, созданных после 13 ноября 2023 года, обычно требуется закрытое тестирование: не менее 12 участников должны оставаться подключенными 14 дней подряд. После этого владелец подает заявку на доступ к рабочей публикации и отвечает на вопросы о тестировании. Не стоит набирать участников в последний вечер только ради числа. Дайте им несколько понятных сценариев, собирайте замечания и исправляйте ошибки: эти сведения пригодятся в заявке.

Следующая дата связана с технической сборкой. С 31 августа 2026 года новые приложения и обновления для обычных смартфонов и планшетов должны быть нацелены на Android 16, то есть уровень API 36 или выше. Для Wear OS и Android Automotive установлен уровень 35, для Android TV и Android XR — 34. У уже опубликованных приложений есть отдельное требование к доступности для новых пользователей. Точное значение лучше каждый раз сверять на официальной странице уровней API, а не брать из прошлогоднего плана.

Следующий этап проверки разработчиков Android начинается 30 сентября 2026 года, но это не единый срок для всех стран. Согласно календарю Google, сначала правила затронут Бразилию, Индонезию, Сингапур и Таиланд: участвующие магазины и сертифицированные устройства с Android 7 и новее. Расширение на другие рынки запланировано на 2027 год. Проверьте состояние пакета в Play Console, не полагаясь только на автоматическую регистрацию.

Соберите единый набор сведений о выпуске

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

Мы советуем завести одну короткую страницу с фактами о подписанной сборке и назначить человека, который её закроет перед отправкой. Большой бюрократии здесь не нужно:

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

Заполняйте «Безопасность данных» по коду и настройкам

Раздел «Безопасность данных» — это структурированное описание сбора и передачи информации. Политика конфиденциальности объясняет то же самое пользователю более подробно. Документы должны совпадать, но один нельзя заполнять догадками на основе другого.

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

Имеет значение не только вид данных, но и цель. Адрес почты для входа и тот же адрес, отправленный в рекламную систему, — разные случаи. Зафиксируйте, покидает ли информация устройство, обязателен ли ее сбор, шифруется ли передача и может ли пользователь потребовать удаление. Сохраняйте перечень библиотек и снимки их настроек вместе с материалами выпуска: при следующем обновлении это избавит от заполнения по памяти.

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

Сделайте удаление аккаунта настоящей функцией

Если аккаунт можно создать внутри приложения, Google Play требует дать пользователю возможность запросить удаление и в самом приложении, и через отдельную веб-страницу, указанную в консоли. Адрес поддержки, спрятанный в длинном документе, не заменяет понятный путь.

Пройдите сценарий на реальной учетной записи. Легко ли найти удаление? Работает ли внешняя страница без входа? Указано ли, что будет удалено, какие сведения могут сохраниться и на какой срок? Действительно ли сервер удаляет или обезличивает нужные записи? Что происходит с действующей подпиской, незавершенным заказом, чеком, спором между участниками маркетплейса или опубликованным контентом?

Данные часто находятся не только в таблице пользователей. Они могут остаться в системе входа, хранилище файлов, службе рассылок, поддержке и резервных копиях. Руководитель продукта описывает ожидаемый результат для пользователя, а разработчики — действие каждой системы.

Уберите лишние разрешения

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

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

На конец октября 2026 года Google объявил новые правила для контактов и точного местоположения, а также дополнительные автоматические проверки перед отправкой. Приложениям под Android 17 стоит заранее изучить средство выбора контактов и новую кнопку местоположения. Курьерскому приложению может быть нужен длительный доступ к геопозиции, а функции приглашения друзей — нет.

Технические вопросы хранения, серверных прав и секретов разобраны в чек-листе безопасности Android-приложения. Здесь же важно убедиться, что сведения в магазине честно описывают реализованную защиту.

Дайте проверяющему постоянный доступ

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

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

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

Карточка магазина должна показывать существующий продукт

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

Используйте настоящие экраны приложения. Их можно оформить для рекламы, но показанный сценарий должен существовать. Если на изображениях есть текст, подготовьте отдельные версии для языков публикации и проверьте валюту, даты и условия оплаты. Размеры и набор материалов есть в статье о скриншотах для Google Play, а языковые версии — в чек-листе локализации магазина.

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

Заполните декларации, которые относятся к продукту

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

Если пользователи публикуют материалы или общаются, нужны понятные правила, жалобы, блокировка и действующий процесс рассмотрения обращений. Для детской аудитории применяются требования программы для семей. Медицинские и финансовые продукты требуют особенно аккуратных формулировок. При продаже цифрового контента или функций заранее проверьте действующие правила Google Play о платежах и исключения для нужного рынка.

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

Проверяйте именно подписанную сборку

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

Установите приложение с нуля, обновите предыдущую версию, создайте и восстановите аккаунт, откажите в разрешениях, включите слабую сеть, проведите основной платеж или бронирование, откройте внешние ссылки и проверьте все роли, выданные Google. Следите, чтобы тестовая оплата случайно не стала настоящей. Во время закрытого теста собирайте сведения об ошибках и показателях Android.

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

Проверка за 48 часов до отправки

За два дня до отправки перестаньте добавлять необязательные библиотеки и рекламные обещания. Соберите окончательную версию и назначьте ответственных.

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

Во второй день человек вне основной команды проходит инструкцию Google на чистом устройстве. Ответственный открывает все публичные ссылки, сравнивает «Безопасность данных» со списком библиотек, сохраняет копию заполненных форм и подтверждает, что доступ к аккаунту Play Console принадлежит компании. После этого сборку можно отправлять.

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

Как выглядит заполненная проверка релиза

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

Так же проверяется доступ для модератора. Зафиксируйте, что на чистой установке демонстрационный аккаунт открывает платное тестовое занятие без одноразового кода и настоящего списания. Если завтра изменится сервер и аккаунт перестанет работать, прежняя проверка уже не подтверждает готовность. Повторно проверьте затронутый сценарий, а не пытайтесь вспомнить, кто что тестировал.

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

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