Дедлайн Google Play: почему приложение исчезает из каталога и как это исправить

Google Play закрывает доступ к приложению, если разработчик не обновил target API level в срок: сначала блокируются установки на новых устройствах, затем карточка исчезает из поиска, а через некоторое время неисправленное приложение снимают с публикации полностью. Для B2B-компании это разрыв канала заказов и потеря доступа клиентов к сервису без предупреждения.

откуда берётся дедлайн, из-за которого приложение исчезает из Google Play

Google ежегодно поднимает планку target API level — минимальную версию Android, под которую обязано быть собрано приложение, чтобы оставаться в каталоге. Для новых приложений срок обычно наступает к концу лета, для обновлений существующих — на пару месяцев позже. Разработчик получает письмо в Play Console за несколько месяцев, но письмо часто уходит на почту, которую никто не проверяет: агентство сдало проект два года назад, штатного мобильного разработчика в компании нет, а входящие от Google фильтруются как рассылка.

Промежуточные стадии редко замечают вовремя: сначала ограничивается видимость для новых пользователей с последней версией Android, затем приложение пропадает из поиска и подборок, и только на последнем шаге Google снимает карточку с публикации полностью. Между первым предупреждением и снятием обычно проходит несколько недель — этого времени достаточно, чтобы всё исправить, если про дедлайн вообще узнали.

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

Кроме target API level дедлайн может касаться других требований: перехода на новую политику работы с разрешениями, обязательного заполнения формы Data safety, смены подписи APK на App Bundle или подтверждения владельца аккаунта разработчика. Механизм один и тот же — сначала предупреждение, потом ограничение видимости для новых пользователей, затем полное снятие с публикации.

сценарий, который встречается чаще всего: приложение для торговых представителей

У дистрибьютора из Москвы 40 торговых представителей принимают заказы через мобильное приложение, синхронное с 1С:Управление торговлей: агент оформляет заявку на складе клиента, она падает в очередь обмена и уходит в учётную систему за несколько минут. В понедельник утром приложение перестаёт открываться на телефонах с Android 15 — вместо запуска Google Play показывает карточку «это приложение больше не поддерживается на вашем устройстве».

ИТ-директор поднимает почту и находит письмо от Google трёхмесячной давности: срок обновления target API level истёк в прошлую пятницу. Но пока приложение недоступно, агенты либо не оформляют заявки вовсе, либо диктуют их по телефону вручную — и часть заказов теряется или задваивается при ручном вводе. Компания, у которой внедрение 1С:Управление торговлей закрывало весь цикл от заявки до отгрузки, за один день теряет главный канал приёма заказов, а склад — актуальную картину остатков.

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

как исправить ситуацию, если приложение уже удалено или заблокировано

Первым делом открывают раздел Policy в Play Console и смотрят точную формулировку нарушения — она обычно конкретна: «target API level below required» или ссылка на политику, которую задело обновление. Дальше порядок такой:

• ✓поднять targetSdkVersion в проекте и пересобрать приложение на актуальном Android SDK;
• ✓прогнать регресс на реальных устройствах, а не только на эмуляторе — новые версии Android чаще всего ломают именно фоновую синхронизацию и push-уведомления;
• ✓если приложение обменивается данными с 1С через HTTP-сервис, проверить, не требует ли новая версия Android принудительный TLS или запрет cleartext-трафика — это частая причина, по которой обмен с учётной системой перестаёт работать даже после пересборки;
• ✓отправить сборку на повторную проверку и держать под рукой запасной канал связи с клиентами на время модерации.

Отдельно стоит проверить формат сборки: Google давно требует App Bundle вместо APK и подпись через Play App Signing — если ключ подписи потерян или сборка всё ещё в старом формате, повторная публикация не пройдёт модерацию даже после исправления версии SDK.

если модерация не проходит с первого раза

Google иногда отклоняет повторную сборку по смежной причине, которую не заметили при первом исправлении: например, устаревшая формулировка в разделе Data safety или разрешение, которое приложение запрашивает, но не использует. В таком случае помогает не спорить с автоматической проверкой, а сразу разобрать полный список требований к текущей версии API и закрыть их все за один заход — повторная модерация может занять ещё несколько дней, и каждый лишний цикл — это дни простоя канала заказов.

Если приложением не занимались два-три года, простым поднятием версии не обойтись: библиотеки устарели, часть API Google отозвала, а верстка не переживёт новый сборщик. В такой ситуации разумнее не латать, а пересобрать критичные модули заново — у нас такая переработка мобильного приложения начинается от 500 000 руб., в зависимости от объёма функциональности и глубины интеграции с учётной системой. Если же барахлит именно обмен с 1С, а не сама витрина приложения, обычно достаточно точечной доработки — доработка 1С под новый протокол обмена занимает заметно меньше времени, чем переписывание мобильной части.

почему история с дедлайном Google Play повторяется у одних и тех же компаний из года в год

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

Разорвать цикл помогает простое правило: обновление targetSdkVersion ставится в календарь заранее, а не после письма от Google, и делается частью того же регламента, по которому обновляется учётная система. Если 1С на стороне бэкенда тоже годами не трогали, риски накладываются друг на друга: новая версия приложения ждёт правки обмена, а обновление 1С откладывается, потому что «и так работает». В итоге оба контура — мобильный и учётный — оказываются устаревшими одновременно, и починка занимает не неделю, а месяц.

что сделать, чтобы дедлайн Google Play больше не был сюрпризом

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

• ✓подписаться на уведомления Play Console на рабочую почту, а не на личную почту бывшего подрядчика;
• ✓закладывать один плановый релиз в год под новый target API level, даже если функционально в приложении ничего не меняется;
• ✓держать актуальными зависимости и SDK, чтобы обновление версии не превращалось в переписывание половины кода;
• ✓публиковать обновления сначала на closed или open testing track, чтобы поймать критичные баги до массового релиза;
• ✓следить за отчётами о сбоях и долей пользователей на старых версиях приложения — резкий рост числа неактуальных клиентов почти всегда сигнал о приближающемся дедлайне;
• ✓для B2B-приложений, критичных для бизнеса, рассмотреть параллельное размещение в реестре российского ПО и альтернативных каталогах — это снижает зависимость от решений одной площадки. Требования и порядок включения описаны в реестре российского ПО.

Отдельно стоит развести ответственность: кто следит за мобильным приложением и кто — за учётной системой, с которой оно обменивается данными. Когда за оба контура отвечает один и тот же подрядчик на регулярном сопровождении, дедлайн Google перестаёт быть сюрпризом — обновление SDK и правки обмена планируются в одном спринте.

сколько стоит поддержка приложения, чтобы не попасть под блокировку

Стоимость зависит от того, на каком этапе бизнес спохватился. Плановое ежегодное обновление targetSdkVersion при живом проекте — это несколько дней работы. Экстренная реанимация заблокированного приложения с устаревшим стеком — совсем другие деньги и сроки. Если параллельно требуется правка обмена с 1С, ориентир по стоимости работ на стороне учётной системы — сопровождение 1С и сисадмин от 3800 руб/час. Разумный момент для планового обновления — за два-три месяца до объявленного Google срока, пока есть запас на тестирование и, если нужно, повторную модерацию.

Дороже всего обходится не сама доработка, а простой: пока приложение недоступно, отдел продаж переходит на ручной ввод заказов, а склад работает по вчерашним остаткам. Регулярное сопровождение обходится в разы дешевле, чем разбор завала после того, как приложение неделю провисело вне Google Play.

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

Как узнать, что моему приложению грозит удаление из Google Play?

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

Сколько времени есть на исправление после блокировки Google Play?

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

Может ли устаревшая версия 1С стать причиной сбоя обмена после обновления приложения?

Да. Если приложение обновили под новый Android, а протокол обмена с 1С остался прежним, синхронизация заказов может перестать работать из-за требований к TLS или изменений в API. В этом случае нужна отдельная доработка обмена на стороне 1С, а не только пересборка приложения.

Что делать, если подрядчик, который делал приложение, недоступен?

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

Стоит ли размещать приложение ещё и в реестре российского ПО?

Для B2B-сервисов, которые критичны для работы бизнеса, это разумная страховка на случай блокировок и решений одной площадки. Включение в реестр российского ПО не заменяет работу с Google Play напрямую, но снижает риск полной потери канала продаж, если правила магазина изменятся резко и без предупреждения.