Приложение на Android использует FCM, но на устройстве без Google Play services push не приходит: какой эксперимент отделит отсутствие поддерживаемого провайдера доставки от ошибки сервера?
Установите ту же сборку на два устройства: обычное Android-устройство с Google Play services и устройство без них, очистив данные приложения перед тестом. Сравните результат регистрации в FCM, наличие токена на сервере и отправку тестового сообщения. Если на устройстве без сервисов регистрация FCM невозможна или токен не создаётся, а на контрольном устройстве тот же сценарий проходит, причина находится в несовместимости провайдера, а не в серверной доставке.
Мобильные push-уведомления доставляются не напрямую от сервера приложения к процессу приложения. Между ними находится системный или vendor-зависимый транспорт, который поддерживает соединение, учитывает энергосбережение и передаёт событие приложению.
Экосистема Android неоднородна: Google Play services не являются обязательной частью каждой Android-системы. Поэтому приложение, рассчитанное только на FCM, не может считать наличие Android достаточным условием для работы push-уведомлений.
Сервер может успешно принять запрос на отправку и получить положительный ответ от FCM, но это не доказывает, что конкретное устройство способно зарегистрироваться в FCM или показать уведомление. На устройстве без поддерживаемого транспорта проблема проявится раньше — при регистрации, получении токена или выборе провайдера.
Если тестировать только серверный ответ, несовместимость устройства можно ошибочно принять за задержку доставки, неверный токен или сетевой сбой. Последствие — приложение будет обещать push на устройствах, где фактически не предусмотрен рабочий канал доставки.
Сначала зафиксируйте матрицу условий: одна версия приложения, одинаковая тестовая учётная запись, один серверный проект и контрольное устройство с рабочими Google Play services. На обоих устройствах выполните чистую установку или очистку данных, чтобы исключить использование старого токена.
Затем проверьте последовательность событий:
На контрольном устройстве успешная регистрация и доставка подтверждают, что базовая конфигурация сервера и содержимое сообщения работоспособны. На устройстве без Google Play services отсутствие FCM-регистрации при тех же остальных условиях указывает на неподдерживаемый транспорт. Однако серверный ответ об успешной отправке нельзя считать доказательством отображения уведомления: доставка и показ зависят также от состояния ОС, разрешений и настроек энергосбережения.
Важно отличать отсутствие FCM от отсутствия push вообще. Если продукт должен работать на устройствах без сервисов Google, приложение должно поддерживать совместимый vendor-провайдер или иной предусмотренный канал. Проверять в таком случае нужно уже регистрацию в выбранном провайдере и маршрутизацию токена к нему, а не пытаться доказать работоспособность FCM.
После выпуска приложения пользователи отдельных Android-устройств перестали получать уведомления. Сервер показывал успешную отправку, поэтому рассматривались варианты: повторная отправка на устаревший токен, блокировка уведомлений пользователем и ошибка сети.
Проверка только на эмуляторе с сервисами Google была недостаточной. Вариант с ручной проверкой уведомления на каждом устройстве давал результат, но не показывал, на каком этапе нарушается цепочка; вариант с анализом только серверных логов не отделял принятие сообщения FCM от его доставки на устройство.
Был выбран сравнительный тест чистой установки на контрольном устройстве с Google Play services и на проблемном устройстве без них. На контрольном устройстве токен создавался и сохранялся на сервере, а на проблемном регистрация FCM не завершалась. Поэтому причиной признали отсутствие поддерживаемого FCM-провайдера, после чего для соответствующих устройств добавили отдельный поддерживаемый канал и явную диагностику недоступности FCM.
Нет. Ответ подтверждает принятие запроса инфраструктурой FCM, но не гарантирует получение приложением, показ уведомления пользователю или своевременную обработку. Для теста полезно разделять серверное принятие, доставку в приложение и отображение; последнюю стадию следует подтверждать наблюдаемым результатом на устройстве, а не только серверным логом.
Токен может быть устаревшим, принадлежать другой установке или сохраниться после восстановления данных. На чистой установке нужно получить новый результат регистрации и сопоставить его с конкретным экземпляром приложения. Иначе серверная запись создаёт ложное впечатление, что устройство поддерживает FCM и готово получать сообщения.
Нужно явно определить поддерживаемый альтернативный транспорт и проверить его полный жизненный цикл: доступность SDK или системного компонента, регистрацию, выдачу токена, передачу токена на сервер, отправку через правильного провайдера и получение сообщения. Нельзя считать замену FCM простым изменением серверного URL: у провайдеров различаются форматы токенов, аутентификация, ограничения и правила обработки уведомлений.