Google Play меняет требования 31 августа: что проверить владельцу приложения

API 36 для новых релизов, доступность старых приложений и новые требования 2027 года — без путаницы между разными сценариями.

Материал подготовила команда 13FOX (tfox.dev). Мы создаём сайты, мобильные приложения и цифровые сервисы для бизнеса и показываем, как принимать продуктовые решения по проверяемым данным.

В календаре владельца приложения 31 августа выглядит как техническая дата. На практике это дата, после которой одна команда не сможет отправить обновление, а другой продукт начнёт терять видимость для новых пользователей современных Android-устройств.

Проблема не решается одной заменой числа targetSdk. Новый уровень API меняет поведение разрешений, уведомлений, фоновых задач, хранилища, ссылок и сторонних SDK. Формально правильная сборка ещё должна пройти критический путь на реальных устройствах.

Ниже — рабочий разбор для владельца продукта: какой порог относится именно к вам, что проверить в Play Console и какие доказательства запросить у команды до отправки релиза.

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

Аккаунт подрядчика Бизнес не контролирует владельца, восстановление и платежи.

Временный package После первой загрузки идентичность не переименовать.

Декларации «по памяти» Поведение SDK и backend осталось за рамкой.

Нет P0 и дежурства Одобрение не доказывает работоспособность production.

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

Для Wear OS, Android TV, Android Automotive OS и Android XR действуют отдельные уровни. Проверять нужно свою форму устройства и свой сценарий: новая публикация, обновление или доступность уже размещённого приложения.

Начинайте не со сборки, а с издателя. 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 уменьшает риск не только публикации, но и будущих обновлений, апелляций и срочного восстановления аккаунта.

Новые приложения публикуются через 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 мог точно назвать проблемную версию, а разработка — повторить её без догадок.

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 проверяйте заранее: поздняя замена участника может не сохранить требуемое окно. Перед заявкой сформулируйте, кто тестировал, какие сценарии прошли, что сломалось, что команда изменила и почему продукт готов к реальным пользователям. Эти ответы должны опираться на журнал, а не на рекламное описание.

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 остаётся отражением системы, а не архивной анкетой первого запуска.

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 по своему трафику и риску.

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 учитывал реальный отказ.

26 августа Google объявил следующий слой технических требований. С февраля 2027 года площадка начнёт применять пороги по использованию памяти и минимальной оптимизации DEX-кода, а с апреля 2027 года потребует поддерживать восстановление входа без повторного ввода данных там, где сценарий применим.

Это не причина срочно переписывать приложение за выходные. Но это причина уже сейчас открыть Android vitals, проверить реальные показатели на устройствах пользователей и включить новые требования в план следующих релизов. Иначе команда снова узнает о проблеме не из своего мониторинга, а из предупреждения Play Console.

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

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

Есть промежуточный случай: приложение готово, но компания упирается в оплату нового developer account, верификацию или получение production access. Для personal accounts, созданных после 13 ноября 2023 года, Google требует закрытый тест минимум с 12 участниками в течение 14 непрерывных дней, а затем отдельную заявку на доступ к production.

В такой ситуации 13FOX может предложить публикацию через действующий аккаунт с уже открытым production-доступом, если эта схема подходит проекту и правилам Google Play. Это не отменяет техническое тестирование, проверку требований и review конкретного приложения. До старта письменно фиксируются правообладатель, имя издателя в магазине, доступ к статистике, порядок обновлений, поддержки и возможного переноса приложения.

Откройте предупреждения Play Console и зафиксируйте три вещи: текущий target API, тип ближайшего действия — новая публикация, обновление или поддержка существующего продукта — и доступность запроса на продление.

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

Материал подготовила команда 13FOX (tfox.dev). Мы разрабатываем и сопровождаем мобильные продукты и переводим требования магазинов приложений в проверяемый план выпуска.