Интеграция push-уведомлений Huawei Push Kit с runtime детектом

Интеграция push-уведомлений Huawei Push Kit с runtime детектом

При разработке Android-приложений под страны СНГ и Китая мы часто сталкиваемся с ситуацией: заказчик теряет до 30% пользователей только потому, что push-уведомления не работают на устройствах Huawei без Google Play. Правильная интеграция Huawei Push Kit с runtime-детектом GMS/HMS решает эту проблему. Мы реализовали такой подход в 15 коммерческих проектах — это позволяет поддерживать единый APK и экономить до 25% бюджета на push-инфраструктуре. В этой статье разберём ключевые шаги: от определения доступного сервиса до серверной отправки и тестирования.

Как определить, какой push-сервис доступен?

Ключевое решение — как обрабатывать оба сценария в одном приложении. Есть два подхода.

Runtime detection — проверяем при запуске, есть ли GMS или HMS, и регистрируемся в нужном сервисе. Этот метод предпочтительнее, так как не требует разделения APK.

object PushProvider {
    fun register(context: Context) {
        when {
            isGmsAvailable(context) -> registerFcm()
            isHmsAvailable(context) -> registerHms(context)
            else -> Log.w("Push", "No push service available")
        }
    }

    private fun isGmsAvailable(context: Context): Boolean =
        GoogleApiAvailability.getInstance()
            .isGooglePlayServicesAvailable(context) == ConnectionResult.SUCCESS

    private fun isHmsAvailable(context: Context): Boolean =
        HuaweiApiAvailability.getInstance()
            .isHuaweiMobileServicesAvailable(context) == ConnectionResult.SUCCESS
}

Вариант 2: отдельные APK / flavor через Gradle productFlavors. Каждый флавор содержит только нужные зависимости. Однако runtime detection проще и поддерживает один APK, что сокращает время на поддержку в 2 раза — это доказано нашими проектами.

Почему runtime detection лучше отдельных сборок?

Отдельные сборки требуют дублирования кода и настройки двух pipeline в CI/CD. Любое изменение (например, добавление нового экрана) приходится вносить дважды. Runtime detection же работает в едином коде: достаточно одной проверки при старте. Это снижает вероятность ошибок и ускоряет разработку на 40%.

Подключение HMS SDK

Структура аналогична FCM: в agconnect-services.json — аналог google-services.json. Скачивается из AppGallery Connect. Размещается в app/ директории. Для подключения добавьте плагин AGCP и зависимость push в Gradle (версии актуальны на момент интеграции).

Сервис для обработки сообщений

class HmsPushService : HmsMessageService() {

    override fun onNewToken(token: String?) {
        token ?: return
        ApiClient.registerHmsToken(token, provider = "HMS")
    }

    override fun onMessageReceived(message: RemoteMessage?) {
        message ?: return
        val data = message.dataOfMap
        val title = data["title"] ?: return
        val body = data["body"] ?: return
        NotificationHelper.show(applicationContext, title, body, data)
    }
}

Регистрируем в AndroidManifest.xml:

<service
    android:name=".HmsPushService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.huawei.push.action.MESSAGING_EVENT" />
    </intent-filter>
</service>

Получение токена вручную

// Асинхронно через Task API
HmsInstanceId.getInstance(context).getToken(APP_ID, HmsMessaging.DEFAULT_TOKEN_SCOPE)
    .addOnSuccessListener { token ->
        ApiClient.registerHmsToken(token, provider = "HMS")
    }
    .addOnFailureListener { e ->
        Log.e("HMS", "Get token failed: ${e.message}")
    }

APP_ID — берётся из agconnect-services.json. Токены HMS и FCM — разные, поэтому сервер должен хранить провайдера вместе с токеном.

Серверная отправка через HMS REST API

Endpoint: https://push-api.cloud.huawei.com/v1/{appId}/messages:send. Аутентификация — OAuth2 Bearer token, получается через https://oauth-login.cloud.huawei.com/oauth2/v3/token с client_id и client_secret из AppGallery Connect. Токен живёт 1 час.

{
  "message": {
    "data": "{\"title\":\"Новое сообщение\",\"body\":\"Иван написал вам\"}",
    "token": ["hms_device_token_here"],
    "android": {
      "notification": {
        "title": "Новое сообщение",
        "body": "Иван написал вам",
        "click_action": {
          "type": 1,
          "intent": "myapp://message?id=123"
        }
      }
    }
  }
}

По данным Huawei, Push Kit обеспечивает доставку более 99% сообщений в течение 30 секунд на устройствах с HMS Core.

Сравнение FCM и HMS: что выбрать?

Если ваша аудитория включает СНГ или Китай, HMS — обязательная опция. Runtime detection позволяет обслуживать оба сервиса из одного APK без дублирования кода.

Типичные ошибки при интеграции HMS

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

HMS поддерживает два типа сообщений: display (отображается системой) и data (только данные). Для data-сообщений, которые должны обрабатываться в фоне, установите foreground_show: false в payload. Это позволит вашему HmsMessageService получать сообщения даже после закрытия приложения.

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

Для тестирования нужно физическое Huawei-устройство без GMS или эмулятор из Huawei DevEco Studio. В AppGallery Connect → Push Kit → Test есть встроенный интерфейс для отправки тестовых push на конкретный токен. Рекомендуем также проверить обработку data-сообщений при свёрнутом приложении — это частая причина сбоев.

Что входит в работу

• Регистрация в AppGallery Connect, настройка Push Kit
• agconnect-services.json и HMS SDK подключение
• HmsMessageService с обработкой data-сообщений
• Runtime-детект GMS/HMS и регистрация в нужном сервисе
• Обновление токена на сервере с указанием провайдера
• Серверная отправка через HMS REST API (или интеграция с провайдером типа OneSignal)
• Тестирование на физическом HMS-устройстве

Сроки

Базовая интеграция HMS Push Kit занимает 1 день. С runtime GMS/HMS детектом, полным lifecycle токена и серверной стороной отправки — 2 дня. Точную оценку получите, написав нам — оценим ваш проект бесплатно.

Если вам нужна интеграция Huawei Push Kit с гарантией доставки — свяжитесь с нами для консультации. Мы поможем настроить единую систему push-уведомлений для любого сценария.

Push-уведомления в мобильном приложении: APNs, FCM, сегментация, rich push

Мы внедрили push-уведомления в мобильном приложении для 50+ проектов — от стартапов до enterprise с аудиторией 10M+ пользователей. Нерелевантное или технически сломанное уведомление хуже его отсутствия: пользователь отключает push или удаляет приложение. Согласно отчёту Localytics, отказ от push-разрешений на iOS достигает 40% в первую неделю — причина почти всегда в нерелевантности, а не в механике. Уже через 2 недели после внедрения качественной сегментации конверсия открытия вырастает на 25–30%. Свяжитесь с нами для аудита текущей реализации — мы оценим проект и предложим оптимальный стек за один день.

Как работает инфраструктура: APNs и FCM

APNs — единственный канал доставки на iOS. Всё остальное (OneSignal, Braze, Airship) — обёртки поверх него. APNs принимает запрос по HTTP/2, аутентификация через JWT-токен (p8-ключ) или сертификат. JWT предпочтительнее: один ключ для всех приложений в аккаунте, не истекает ежегодно в отличие от сертификата. Подробнее — на Wikipedia.

Критический момент: APNs различает apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно указанный тип на iOS 13+ приводит к тому, что background-уведомление не разбудит приложение. Видели проекты, где content-available: 1 отправляли без apns-push-type: background — приложение не получало silent push на части устройств, и команда месяц искала «баг в приложении».

FCM на Android работает через Google Play Services. Для устройств без GMS (Huawei, часть китайского рынка) нужен Huawei Push Kit или прямой WebSocket — отдельная задача. FCM поддерживает data-сообщения (обрабатываются в onMessageReceived) и notification-сообщения (система отображает автоматически, если приложение в фоне). Смешивать их нужно осторожно: если в notification-блоке есть click_action, а deep link в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.

Почему сегментация — основа эффективных push-уведомлений?

Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Персонализированные сообщения кликают в 3 раза чаще массовых, а правильная сегментация снижает отток на 25% (на одном из проектов это принесло дополнительный доход 3 млн рублей за квартал). Стоимость настройки сегментации в OneSignal или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, но нет гибкой фильтрации.

Сегменты по атрибутам — через OneSignal, Braze или кастомный бэкенд. Храним в профиле пользователя: язык, тип устройства, последняя активность, LTV-сегмент. Уведомление уходит только тем, у кого last_active < 7_days и plan = premium. OneSignal позволяет строить такие фильтры в интерфейсе без кода.

Персонализированные — по конкретному device_token. Важно хранить токены правильно: токен обновляется при переустановке приложения, при восстановлении из бэкапа на новый телефон, при сбросе настроек. На iOS используем UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, сохраняем на бэкенд при каждом запуске, не только при первом. Иначе через 3 месяца 30% токенов в базе устаревшие.

Что такое rich push и как он повышает конверсию?

Стандартное уведомление с заголовком и текстом кликают реже, чем rich push с картинкой и кнопками действий — в 3 раза. Но реализация rich push — отдельная работа на каждой платформе.

На iOS rich content требует UNNotificationServiceExtension (для модификации payload) и UNNotificationContentExtension (кастомный UI). Расширение запускается в отдельном процессе с ограниченным временем и памятью. Если расширение падает или превышает таймаут, система показывает оригинальный payload без медиа. Типичная ошибка — пытаться загрузить изображение по HTTP (не HTTPS): ATS заблокирует запрос, расширение молча завершится, пользователь увидит уведомление без картинки.

На Android с API 26+ уведомления привязаны к NotificationChannel. Если канал создан с IMPORTANCE_LOW, звук и вибрация недоступны. Разные типы уведомлений (транзакционные, маркетинговые) должны быть в разных каналах, чтобы пользователь мог отключить маркетинг, не теряя уведомлений о заказах. BigPictureStyle, MessagingStyle, InboxStyle — шаблоны для расширенных уведомлений. MessagingStyle с Person и аватарками — лучший выбор для чатов.

Как отследить доставку и конверсию push-уведомлений?

Отправить уведомление — полдела. Важно знать: доставлено ли оно, открыто ли, привело ли к целевому действию.

FCM отдаёт MessageId при отправке, но не гарантирует коллбэк о доставке — это by design. Для tracking открытий нужна кастомная логика: при тапе на уведомление в onMessageReceived или через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) отправляем событие в аналитику с notification_id.

OneSignal предоставляет встроенную аналитику доставки и CTR. Для более детального анализа — интегрируем с Amplitude или Mixpanel через webhook на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

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

1. Аудит текущей реализации — проверяем хранение токенов, обработку обновлений, типы уведомлений.
2. Проектирование архитектуры — выбираем транспорт (FCM + APNs), слой сегментации (OneSignal/Braze/кастом), способ персонализации.
3. Реализация — пишем код регистрации, обработки входящих, rich push, deep linking.
4. Тестирование — отправляем тестовые кампании, проверяем доставку на разных устройствах, симуляторах, регионах.
5. Мониторинг и аналитика — настраиваем дашборд, события открытия и конверсий.
6. Документация и обучение — передаём команде материалы по эксплуатации.

Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда используем Braze или собственную реализацию на AWS SNS.

Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель. Закажите аудит текущей push-инфраструктуры или получите консультацию по внедрению push-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.