Приложение не проходит Google Play: как подготовить бизнес-приложение к Android 16 и API 36

Сроки Google Play и первый шаг

С 31 августа 2026 года Google Play требует, чтобы новые приложения и обновления существующих были собраны с targetSdkVersion не ниже 36, то есть ориентированы на Android 16. Для Wear OS и Android Automotive OS порог ниже — API 35, для Android TV и Android XR — API 34. При необходимости можно запросить продление до 1 ноября 2026 года через форму, которая появляется в Play Console при обнаружении несоответствия [1].

Это требование магазина приложений, а не изменение в самой ОС на телефонах пользователей и не норма российского законодательства. Пользователи, у которых приложение уже установлено, продолжат им пользоваться независимо от того, обновит компания приложение к сроку или нет [1]. Проблема возникает в тот момент, когда бизнесу нужно выпустить любое новое обновление — от косметической правки интерфейса до критичного исправления в оплате.

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

В чём разница между «не примут новое приложение», «не примут обновление» и «скроют от новых пользователей»

Здесь стоит развести три разных сценария, которые Google Play описывает отдельно [1]:

Новое приложение. Если компания только выходит в Google Play с новым продуктом, публикация возможна только с targetSdkVersion 36 и выше (кроме указанных выше форм-факторов). Отсрочек здесь по сути нет — публикация просто не пройдёт модерацию.

Обновление существующего приложения. Любая новая версия — даже минорный патч — с 31 августа 2026 года должна собираться с target API 36. Если подрядчик пришлёт вам сборку с targetSdk 34 «потому что там ничего критичного не менялось», Play её отклонит.

Доступность уже опубликованного приложения новым пользователям. Это отдельное, более мягкое правило: если приложение вообще не обновлять и оно продолжает целиться в Android 14 или ниже, оно постепенно перестаёт быть доступным для установки новым пользователям с более новыми версиями Android — при этом уже установленные копии продолжают работать [1]. Для действующих (уже опубликованных) приложений порог ниже, чем для новых: достаточно API 35, чтобы не потерять видимость в сторе [1].

Разница критична для бизнес-планирования: если приложение «законсервировано» и обновляться не планируется, у компании технически есть время — но каждый месяц без обновления приложение постепенно теряет часть новых пользователей на актуальных телефонах, а старые пользователи не замечают разницы [1].

Что такое targetSdkVersion и почему это не «просто цифра в файле»

targetSdkVersion — это параметр в манифесте приложения, который сообщает системе, под какое поведение Android приложение спроектировано [1]. Он отличается от minSdkVersion (минимальной версии, на которой приложение вообще может запуститься) и от compileSdkVersion (версии инструментов сборки).

Проблема в том, что при повышении target API Android не просто позволяет использовать новые возможности — он включает новое поведение системы по умолчанию для всех приложений, которые заявили этот target, даже если разработчик не писал ни строчки нового кода. Часть старой логики (например, обработка кнопки «назад» или отключение полноэкранного режима) в API 36 попросту перестаёт работать так, как работала раньше [2]. Именно поэтому «поднять цифру в build.gradle» технически может занять пять минут, а протестировать последствия — недели, в зависимости от возраста и сложности кодовой базы.

Как проверить, что происходит с вашим приложением прямо сейчас

Фактический targetSdk и compileSdk

Первое, что нужно получить от подрядчика или от своей команды — не обещание «мы обновим», а факт: какой targetSdkVersion и compileSdkVersion указаны в текущей боевой сборке приложения и когда планируется их поднять до 36. Это можно попросить показать напрямую в файле сборки или в карточке приложения в Play Console.

Сторонние библиотеки, SDK и плагины

Большинство бизнес-приложений (доставка, клиники, магазины) используют сторонние SDK: платёжные системы, push-уведомления, аналитику, карты, антифрод, чаты поддержки. Google Play анализирует такие зависимости по специальному dependency-файлу, который включается в сборку автоматически при использовании Android App Bundle, и может показывать предупреждения или блокировать релиз, если конкретная версия SDK не соответствует политике [11]. Практический вывод: даже если ваша команда полностью обновила собственный код, релиз может не пройти из-за устаревшей версии стороннего платёжного или рекламного SDK — это нужно проверять отдельно, а не полагаться только на отчёт «наш код готов».

Ограничения текущего подрядчика

Если приложение разрабатывал внешний подрядчик и поддержка была передана другой команде (или заморожена), стоит явно зафиксировать: у кого есть доступ к исходному коду и ключам подписи, кто отвечает за обновление зависимостей, есть ли актуальная сборочная среда (совместимый Android Gradle Plugin, SDK нужной версии), и что произойдёт, если подрядчик недоступен к сроку. Часто выясняется, что «просто обновить цифру» невозможно, потому что проект годами не собирался и требует восстановления окружения.

Что в Android 16 действительно ломает бизнес-сценарии

Ниже — не полный список изменений Android 16, а те, что чаще всего проявляются именно в пользовательских сценариях бизнес-приложений.

Навигация «назад» и интерфейс на весь экран

Начиная с приложений, нацеленных на API 36 и запущенных на Android 16, система по умолчанию включает предиктивную навигацию «назад»: метод onBackPressed() больше не вызывается, а нажатие физической/системной кнопки «назад» обрабатывается иначе [2]. Если в приложении на кнопке «назад» завязана нестандартная логика — например, возврат из карточки заказа в каталог или закрытие формы оплаты с подтверждением — это может сломаться незаметно для разработчиков, но заметно для пользователя.

Одновременно приложения, нацеленные на Android 16, больше не могут отказаться от полноэкранного (edge-to-edge) режима отображения — соответствующий флаг отключения перестаёт действовать [2]. Если экраны оформления заказа или личного кабинета не рассчитаны на этот режим, элементы интерфейса могут перекрываться системными панелями.

Уведомления и фоновые операции

Android 16 продолжает ужесточать квоты на выполнение фоновых заданий: если раньше активный foreground-сервис (например, отслеживание заказа курьера или синхронизация данных) частично освобождал сопутствующие фоновые задачи от лимитов, то теперь такие задачи всё равно подчиняются обычным квотам выполнения [3]. Отдельно действуют временные ограничения для сервисов типа dataSync и mediaProcessing — система принудительно останавливает такой сервис, если он суммарно выполняется дольше 6 часов за 24-часовой период, и приложение обязано корректно завершить работу за отведённое системой время [5].

Отдельная, не новая именно для Android 16, но регулярно всплывающая при таком аудите деталь: приложение, нацеленное на Android 12 и выше, не может запускать foreground-сервис, находясь в фоне, кроме нескольких предусмотренных исключений — при попытке нарушить это правило система выбрасывает исключение [4][8]. Это стоит явно перепроверить в сценариях, где foreground-сервис запускается не по прямому действию пользователя, а по пуш-уведомлению, таймеру или фоновому событию — например, при старте отслеживания заказа курьера сразу после получения push о начале доставки.

Для бизнеса всё это означает риск в сценариях фоновой синхронизации данных (например, докачка результатов анализов в приложении клиники или синхронизация каталога в приложении магазина): если сервис не успевает штатно завершиться или не может корректно запуститься из фона, пользователь может получить не ошибку, а просто «зависшую» или не обновившуюся функцию.

Разрешения и деликатные данные

Для мобильных приложений, которые запрашивают отдельные детализированные разрешения на данные о здоровье (например, чтение частоты сердечных сокращений через связанные с Health Connect механизмы), появляется требование обязательно показывать пользователю экран с политикой конфиденциальности — без этого обоснования системе разрешение может быть отозвано [2]. Это напрямую касается приложений клиник и фитнес-сервисов, если они запрашивают такие данные.

Переходы по ссылкам (deep link) и безопасность

Android 16 вводит инициативу Safer Intents — более строгую, пока опциональную проверку того, какие приложения и компоненты могут получать намерения (intent) от других приложений; разработчикам нужно осознанно включать более строгую обработку, и Google обозначает курс на постепенное расширение этого механизма в будущих версиях [2]. Отдельная, не привязанная напрямую к Android 16, но актуальная для проверки тема — безопасность экспортируемых (exported) компонентов и deep link: если активность, открывающаяся по ссылке (например, «открыть карточку заказа» или «перейти к оплате по ссылке из push-уведомления»), помечена как экспортируемая и без проверки обрабатывает входящие данные, это создаёт риск, что стороннее приложение или сайт смогут инициировать переход в защищённый раздел приложения в обход обычной навигации [10]. Для приложений с оплатой, авторизацией по ссылке или переходом из push-уведомлений это стоит включить в чек-лист тестирования при любом крупном обновлении, не только при смене target API.

Отдельно стоит смежное, но самостоятельное требование: с ноября 2025 года (и жёстко — с мая 2026 года) Google Play проверяет, что нативный код (библиотеки .so), включённый в приложение напрямую или через сторонние SDK, поддерживает работу с памятью на устройствах с размером страницы 16 КБ [6][7]. Формально это не часть требования к target API 36, но на практике оба требования часто «всплывают» в Play Console одновременно при попытке опубликовать обновление, и оба блокируют релиз до устранения.

Тестируем то, что реально приносит деньги

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

Авторизация и вход

Экран логина — один из самых чувствительных к изменению навигации «назад»: если раньше нажатие «назад» на экране входа кастомно возвращало пользователя на предыдущий шаг, после перехода на предиктивную навигацию поведение может измениться, и пользователь неожиданно окажется вне приложения [2]. Отдельно стоит проверить сценарий входа через внешний браузер (OAuth) с возвратом в приложение по deep link — именно такие переходы затрагивает более строгая проверка intent-компонентов [10]. Наконец, из-за автоматического резервного копирования данных приложения при переустановке или переносе на новое устройство в копию может попасть токен авторизации или флаг «уже проходил онбординг» — стоит явно протестировать сценарий «удалил приложение → установил заново» и убедиться, что пользователь не оказывается залогинен под устаревшей сессией или, наоборот, не видит повторно экран регистрации [9].

Оформление заказа и оплата

Проверьте весь путь целиком на устройстве с Android 16: переход в корзину, выбор способа оплаты, переход во внешнее платёжное приложение или SDK и возврат обратно, обработку успешной и неуспешной оплаты, поведение кнопки «назад» на каждом шаге. Если оплата инициируется через deep link или intent от платёжного провайдера, отдельно проверьте, что возврат в приложение приводит именно на нужный экран, а не на главный экран или в корень навигации — это один из типичных побочных эффектов изменения обработки кнопки «назад» [2].

Загрузка файлов и медиа

Если приложение позволяет загружать фото (результаты анализов, фото товара для возврата, документы для доставки), проверьте сценарий на устройстве с Android 16 и, если приложение использует нативный код для обработки изображений или видео, отдельно проверьте совместимость с 16 КБ страницами памяти [6].

Поведение после переустановки и восстановления данных

Android по умолчанию делает автоматическое резервное копирование данных приложения (Auto Backup) в Google Диск пользователя и восстанавливает их при повторной установке — это происходит после установки APK, но до того, как пользователь сможет открыть приложение [9]. Для бизнеса это создаёт нетривиальный, но не новый именно для Android 16 риск: если в резервную копию попадают токены авторизации, флаги «это первый запуск» или локальный кэш заказов, после переустановки пользователь может оказаться залогинен под старой сессией, увидеть устаревшие данные или, наоборот, не пройти обязательный экран онбординга. Обновление target API — хороший повод пересмотреть, какие именно данные приложение исключает из автоматического бэкапа, и явно протестировать сценарий «удалил приложение → установил заново на то же устройство или на новое с тем же Google-аккаунтом».

Мобильный клиент и сервер: как не разойтись

Обновление мобильного клиента редко бывает изолированной задачей. Стоит заранее согласовать с командой, отвечающей за серверные API:

• какие версии мобильного приложения (по target API и по номеру версии) должны оставаться работоспособными после релиза — то есть пользователи со старыми установленными версиями не должны сломаться из-за изменений на бэкенде;
• не приведёт ли обновление клиента к изменению формата запросов, авторизации или обработке пуш-уведомлений, которое требует синхронного изменения на сервере;
• как долго сервер обязан поддерживать API для версий приложения, которые ещё не обновились (у части пользователей это может быть месяцы, так как принудительного обновления Google Play не требует).

Это особенно важно для приложений с активной пользовательской базой: часть пользователей физически не обновит приложение сразу после релиза, и сервер должен уметь работать одновременно со старым и новым поведением клиента какое-то переходное время.

Как выпускать обновление, чтобы не потерять пользователей

Поэтапный выкат и мониторинг ошибок

Google Play позволяет публиковать обновление не сразу на 100% пользователей, а поэтапно — начиная с небольшого процента и постепенно увеличивая охват; при этом можно ограничить выкат конкретными странами [12]. Это разумная практика именно для релиза со сменой target API, потому что часть проблем (особенно связанных с фоновыми операциями или крайними случаями навигации) проявляется не сразу, а при накоплении статистики по реальным пользователям.

Если после начала выката обнаруживается критичная проблема — например, массовые сбои при оплате — Google Play позволяет остановить полностью выкаченный релиз: предыдущая рабочая версия автоматически становится доступной новым и ещё не обновившимся пользователям, при этом резко это не восстанавливает работу уже обновившихся пользователей [13]. Дополнительно на этапе публикации Play Console проводит автоматические предрелизные проверки и может заранее показать часть проблем совместимости ещё до полной модерации [15].

Что делать, если не успеваете к сроку

Если реалистично оценить, что миграция не завершится к 31 августа 2026 года, у компании есть три пути, зафиксированных в правилах Google Play [1][14]:

1. Запросить продление до 1 ноября 2026 года — форма становится доступна в разделе статуса политик (Policy status) в Play Console после того, как система обнаружит несоответствие у конкретного приложения.
2. Не обновлять приложение вовсе и принять, что оно постепенно перестанет быть видимым новым пользователям на актуальных версиях Android, продолжая работать у уже установивших его людей.
3. Снять приложение с публикации (unpublish), если продукт сворачивается или переносится на другую платформу.

Ни один из этих сценариев не требует экстренных решений «за одну ночь» — но каждый требует, чтобы решение было осознанным, а не результатом того, что про требование просто забыли до последнего дня.

Чек-лист: план обновления и требования к подрядчику

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

Проверка текущего состояния

• Зафиксировать фактический targetSdkVersion и compileSdkVersion в боевой сборке.
• Получить список сторонних SDK (платежи, push, аналитика, карты) и их версий, проверить предупреждения в Play Console [11].
• Убедиться, что есть доступ к исходному коду, ключам подписи и рабочей сборочной среде.
• Проверить наличие и совместимость нативного кода (.so-библиотек) с требованием 16 КБ страниц памяти [6][7].

Тестирование на Android 16

• Экран входа и авторизации: поведение кнопки «назад», возврат из OAuth-браузера, сессия после переустановки [2][9][10].
• Оформление заказа и оплата целиком, включая переход во внешние платёжные SDK и обратно [2].
• Загрузка файлов и медиа, если используется нативная обработка изображений/видео [6].
• Фоновые сценарии: синхронизация данных, отслеживание заказа/доставки, работа сервисов, запускаемых по push [3][4][5][8].
• Deep link и переходы по ссылкам из push-уведомлений и внешних источников [10].
• Разрешения на чувствительные данные (здоровье, геолокация), если они используются [2].

Подготовка и выпуск релиза

• Согласовать с бэкенд-командой сроки поддержки старых версий клиента.
• Запланировать поэтапный выкат вместо публикации сразу на 100% пользователей [12].
• Подготовить план отката (halt rollout) на случай критичной ошибки [13].
• Если срок не будет соблюдён — заранее проверить в Play Console, появилась ли форма запроса продления, и принять решение: продление, временная пауза в обновлениях или снятие с публикации [1][14].

Типичные ошибки бизнеса при таких обновлениях

• Считать смену targetSdkVersion чисто технической задачей уровня «поменять одну строку» и не закладывать время на регрессионное тестирование ключевых сценариев.
• Не проверять версии сторонних SDK (платежи, аналитика, push) отдельно от собственного кода команды.
• Тестировать только на эмуляторах последней версии Android и не проверять, что старые установленные версии приложения продолжают нормально работать с обновлённым сервером.
• Выкатывать обновление сразу на 100% пользователей без поэтапного выката и без плана отката.
• Не проговаривать заранее с подрядчиком, кто отвечает за обновление до истечения срока и что произойдёт, если он не успевает.

Что учитывать российской компании

Важно чётко разделять две вещи. Требование target API 36 — это правило магазина приложений Google Play, а не норма российского законодательства и не техническое требование к операционной системе на устройствах пользователей [1]. Оно в равной степени касается любой компании, публикующей приложение в Google Play, независимо от страны. При этом у российских компаний нередко есть дополнительный практический контекст: ограниченный или нестабильный доступ к части сервисов и SDK экосистемы Google (например, некоторых механизмов push-уведомлений или платёжных интеграций), устаревшие интеграции, которые обновлялись «по остаточному принципу» из-за смены приоритетов, и распространённая практика параллельной публикации в RuStore или через прямую раздачу APK. Подтверждённых открытых данных о том, что конкретно API 36 создаёт новые ограничения именно для российских разработчиков сверх общемировых, найти не удалось — но при планировании миграции стоит заранее уточнить у своей команды, не завязаны ли критичные функции приложения на SDK, обновление которых может быть затруднено по независящим от Google Play причинам.

Как выбрать формат работы: свой подрядчик, аудит или новая разработка

Если у приложения есть активная команда поддержки (своя или подрядная), в большинстве случаев достаточно точечного технического аудита: проверить фактический targetSdk, актуальность зависимостей и SDK, прогнать чек-лист по ключевым сценариям на Android 16, спланировать поэтапный релиз. Полноценная разработка «с нуля» или смена подрядчика оправданы, когда исходный код давно не обновлялся, права на него утеряны или прежняя команда недоступна. Не стоит переоценивать масштаб задачи заранее: для многих приложений на современном стеке (Kotlin/Java без большого количества нативного кода) обновление target API — это в первую очередь тестирование, а не переписывание.

Вывод

Требование Google Play к target API 36 — это не разовая техническая правка, а повод системно протестировать бизнес-критичные сценарии приложения на актуальной версии Android: оплату, авторизацию, уведомления, фоновую синхронизацию и переходы по ссылкам. Срок — 31 августа 2026 года, с возможностью продления до 1 ноября 2026 года через форму в Play Console — даёт время подготовиться осознанно, если начать сейчас, а не в последнюю неделю. Ключевая задача бизнеса — не столько «поднять цифру» в коде, сколько получить от своей команды или подрядчика чёткий ответ: что именно изменится в поведении приложения, что было протестировано и какой план на случай, если после релиза что-то пойдёт не так.

Источники

[1] support.google.com — Target API level requirements for Google Play apps — https://support.google.com/googleplay/android-developer/answer/11926878?hl=en

[2] developer.android.com — Behavior changes: apps targeting Android 16 or higher — https://developer.android.com/about/versions/16/behavior-changes-16

[3] developer.android.com — Behavior changes: all apps — https://developer.android.com/about/versions/16/behavior-changes-all

[4] developer.android.com — Changes to foreground services — https://developer.android.com/develop/background-work/services/fgs/changes

[5] developer.android.com — Foreground service timeouts — https://developer.android.com/develop/background-work/services/fgs/timeout

[6] developer.android.com — Support 16 KB page sizes — https://developer.android.com/16kb-page-size

[7] android-developers.googleblog.com — Prepare your apps for Google Play's 16 KB page size compatibility requirement — https://android-developers.googleblog.com/2025/05/prepare-play-apps-for-devices-with-16kb-page-size.html

[8] developer.android.com — Meet Google Play's target API level requirement — https://developer.android.com/google/play/requirements/target-sdk

[9] developer.android.com — Back up user data with Auto Backup — https://developer.android.com/identity/data/autobackup

[10] developer.android.com — Android intent and component security best practices — https://developer.android.com/agents/skills/security/android-intent-security/SKILL

[11] support.google.com — Using third-party SDKs in your app — https://support.google.com/googleplay/android-developer/answer/10358880

[12] support.google.com — Release app updates with staged rollouts — https://support.google.com/googleplay/android-developer/answer/6346149

[13] support.google.com — Halting a fully rolled-out release — https://support.google.com/googleplay/android-developer/answer/16285429

[14] support.google.com — Update or unpublish your app — https://support.google.com/googleplay/android-developer/answer/9859350

[15] support.google.com — Detect app issues early with pre-review checks — https://support.google.com/googleplay/android-developer/answer/14807773