Уведомления на Android без Google: почему UnifiedPush через ntfy не работает

UnifiedPush через публичный сервер ntfy.sh на Android без сервисов Google работает нестабильно из-за общих лимитов, обрывов фонового соединения на прошивках Xiaomi, Honor и Huawei и отсутствия гарантий доставки. Рабочее решение для бизнес-приложения — собственный сервер уведомлений с авторизацией по токену, который не зависит от чужой очереди и настраивается под конкретный парк устройств.

что такое UnifiedPush и почему бизнес ищет замену Google-пушам

Firebase Cloud Messaging — стандартный канал push-уведомлений на Android, но он работает только через сервисы Google Play. На части корпоративного парка устройств их нет: телефоны на RuStore без GMS, MDM-профили, которые администратор намеренно блокирует политикой безопасности, модели китайских брендов для российского рынка без предустановленных сервисов Google. Приложению нужен альтернативный канал доставки — здесь на сцену выходит UnifiedPush.

UnifiedPush — открытый протокол: на телефоне ставится приложение-дистрибьютор, которое держит одно фоновое соединение с push-сервером и раздаёт уведомления всем приложениям, подписанным на этот канал. Самый быстрый способ его опробовать — публичный сервер ntfy.sh: бесплатный, без регистрации, с готовым Android-клиентом. Для пилота на пяти телефонах такой вариант подходит. Для рабочего B2B-приложения склада, логистики или сервиса заявок — уже нет.

Чаще всего к этой теме приходят компании из трёх сценариев: розница и логистика, где часть парка — недорогие Android-телефоны без Google-сервисов; корпоративные заказчики с жёсткой MDM-политикой, где Google Play отключён централизованно; и разработчики, которые публикуют приложение в RuStore и хотят push-канал, не зависящий от инфраструктуры Google в принципе, а не только для устройств без GMS. Во всех трёх случаях требование одно: доставка уведомлений не должна зависеть от того, есть ли на конкретном телефоне сотрудника Google Play — а публичный ntfy.sh такую независимость обещает только на словах.

почему возникает сбой доставки уведомлений через публичный ntfy

Курьерская служба в Балашихе получает заказы через мобильное приложение, интегрированное с 1С: менеджер проводит документ — экспедитор видит push о новом заказе через 20–30 секунд. Во вторник вечером уведомление о срочном заказе пришло экспедитору через 40 минут: клиент к этому моменту уже отменил доставку и ушёл к конкуренту.

Дело было не в 1С и не в самом приложении. Сообщение ушло на ntfy.sh вовремя, но встало в общую очередь публичного сервера, а телефон на Honor к тому моменту уже разорвал фоновое соединение экономией заряда — типичное поведение прошивок EMUI и MagicOS для приложений без привилегий Google Play.

публичный сервер не даёт гарантий доставки

ntfy.sh — общая инфраструктура на бесплатном тарифе: лимит на число сообщений и подписчиков на топик, ограничение размера вложений, задержки при пиковой нагрузке от других пользователей сервиса. Имена топиков живут в общем пространстве: если название угадали или нашли в логах, чужой человек может подписаться на уведомления о заказах или опубликовать в топик что-то от имени компании. SLA публичный сервис не даёт — это площадка для тестов, а не рабочая инфраструктура бизнеса.

Android-прошивки убивают фоновое соединение

Google Play Services получает от производителей телефонов привилегированное исключение из экономии заряда. Сторонний дистрибьютор UnifiedPush такого исключения по умолчанию не имеет. На Xiaomi это автозапуск в списке разрешений MIUI, на Huawei и Honor — «защищённые приложения», на Samsung — «неконтролируемые в фоне» приложения. Без явной настройки MIUI разрывает фоновое соединение уже через 10–15 минут после блокировки экрана и не восстанавливает его, пока пользователь сам не откроет приложение.

корпоративная сеть добавляет свой слой ограничений

Даже если телефон настроен правильно, соединение может резать корпоративный Wi-Fi или прокси: часть офисных файрволов пропускает только 443-й порт и режет нестандартные wss-подключения на других портах, часть MDM-профилей блокирует фоновый трафик у неподписанных внутренним сертификатом приложений. Публичный ntfy.sh на это повлиять не может — там нет доступа к настройкам маршрута трафика конкретной компании.

Для сервиса, где решает скорость реакции — логистика, выездной сервис, склад, — пропущенный push не абстрактный риск, а конкретная заявка, о которой менеджер узнаёт не в моменте, а на утренней планёрке. Это отменённые заказы, ручные обзвоны «а вы получили документ» и склад, который двадцать минут не знает, что заказ подтверждён и его пора собирать.

как исправить: перенос push-уведомлений на собственный сервер

разворачиваем свою инсталляцию ntfy

ntfy — open-source проект, его разворачивают на собственном сервере в Docker-контейнере за час: свой домен, свой TLS-сертификат, авторизация по токену на каждый топик вместо угадываемого имени. Число топиков, сообщений и подписчиков ограничивает только сервер компании, а не политика бесплатного тарифа. Топик привязываем не к общему названию, а к конкретному устройству или сотруднику — так утечка одного токена не открывает доступ ко всем уведомлениям сразу. Мы закладываем такую push-архитектуру уже на этапе разработки мобильного приложения — отдельным модулем её потом не пристроить без переделки клиентской части.

настраиваем Android-клиент и обходим ограничения прошивок

При первом запуске приложение объясняет пользователю, зачем нужно разрешение работать в фоне, и ведёт его в нужный раздел настроек: автозапуск на Xiaomi, защищённые приложения на Huawei, отключение оптимизации батареи на Samsung. Без этого шага даже собственный сервер не спасёт — система всё равно разорвёт соединение молча, без ошибки в логах приложения. Отдельно держим foreground-сервис с постоянным уведомлением о работе синхронизации — на части прошивок это единственный способ не дать системе выгрузить процесс из памяти вместе с открытым соединением.

связываем push с документами 1С

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

что делать, если ошибка повторяется

Перенос на свой сервер снимает лимиты публичного ntfy, но не отменяет диагностику: если push всё ещё теряются, причина обычно одна из четырёх.

• ✓корпоративный Wi-Fi или прокси режет нестандартные порты — переносим ntfy на 443-й порт поверх wss, большинство файрволов его не трогает;
• ✓после обновления прошивки телефон сбрасывает разрешение на автозапуск — проверяем это на нескольких моделях из реального парка компании, а не на одном тестовом устройстве;
• ✓токен топика попал в открытый лог или репозиторий — перевыпускаем токен и добавляем ротацию по расписанию;
• ✓сервер не получает подтверждение доставки — добавляем ack от клиента и алерт, если подтверждение не пришло за заданное время.

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

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

как предотвратить потерю уведомлений на новых проектах

Дешевле спроектировать push-архитектуру на старте, чем чинить её после первого сорванного заказа. На старте проекта мобильной разработки мы фиксируем парк целевых устройств заказчика — конкретные модели Xiaomi, Honor, Samsung, которые реально стоят на складе или в машинах у экспедиторов, — и тестируем доставку push именно на них, а не на эмуляторе. Для проектов на 1С:Мобильной платформе логика та же: push-сервер и обработчик событий закладываются в архитектуру сразу, а не пристраиваются отдельным модулем позже.

Ещё один рабочий приём — не завязывать критичные уведомления только на push. Для событий уровня «сорвётся заказ» дублируем канал: если ack от устройства не пришёл за пару минут, система шлёт резервное SMS или сообщение в рабочий чат. Push остаётся быстрым основным каналом, а дублирование закрывает тот редкий случай, когда телефон конкретного сотрудника всё же ушёл в глубокий сон посреди рабочего дня. На старте проекта эту логику фиксируем в техническом задании отдельным пунктом — тогда резервный канал появляется в архитектуре сразу, а не дописывается через месяц после первой жалобы клиента на пропущенный заказ.

Стоимость такой доработки закладывается в проект целиком: разработка мобильного приложения с push-инфраструктурой и интеграцией с 1С начинается от 500 000 руб, точную сумму считаем после технического задания — ориентиры по форматам работ смотрите в тарифах.

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

Можно ли вообще обойтись без Google-сервисов для push-уведомлений на Android?

Да, протокол UnifiedPush для этого и создан: телефон держит одно фоновое соединение с любым push-сервером через приложение-дистрибьютор. Работает на устройствах без GMS и в RuStore. Проблема не в протоколе, а в публичном бесплатном сервере ntfy.sh — своя инсталляция снимает те же ограничения.

Почему приложение с UnifiedPush иногда молчит часами, хотя интернет на телефоне есть?

Обычно систему экономии заряда: MIUI, EMUI и другие прошивки разрывают фоновое соединение дистрибьютора через 10–15 минут после блокировки экрана, если приложение не в списке автозапуска. Интернет работает, а именно push-канал уже закрыт системой.

Сколько стоит перенести push-уведомления на собственный сервер?

Отдельно эту доработку не считаем — она входит в проект мобильного приложения с push-инфраструктурой и интеграцией с 1С, стоимость которого начинается от 500 000 руб. Точная сумма зависит от парка устройств и сценариев уведомлений, её считаем после технического задания.

Нужно ли менять текущее приложение полностью, чтобы перейти на свой сервер уведомлений?

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

Как понять, что причина именно в ntfy, а не в самом мобильном приложении или в 1С?

Проверить по логам сервера: если сообщение ушло на сервер вовремя и подтверждено на стороне ntfy, но не появилось на телефоне, проблема в доставке — публичном сервере или настройках прошивки. Если сообщение не ушло с сервера вовсе, ищите причину в интеграции с 1С.