Android Live Updates и островки производителей: практическое руководство

Обновлено: 6 ноября 2026.

В Android нет одного «островка», который приложение одинаково рисует на всех телефонах. Есть стандартные Live Updates, системные уведомления, фирменные поверхности производителей и отдельные SDK. Надёжная интеграция начинается с подходящего сценария и модели состояния, а заканчивается проверкой конкретных устройств.

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

Проверка документации: 5 ноября 2026 года. Материал разделяет общий Android API, фирменный путь подключения и фактическую поддержку на устройстве. Kotlin-фрагменты иллюстрируют реализацию, но не являются собранным Android-проектом. Макеты авторские и условные; это не скриншоты конкретной прошивки.

1. Как устроены Live Updates

Приложение создаёт уведомление, описывающее текущую активность, и запрашивает повышенную видимость. Система проверяет условия и определяет представление: карточку, блокировку, статусный чип. Производитель может добавлять свои требования. Так устроен стандартный механизм Live Updates.

У него нет обещания произвольного HTML, Compose-экрана или SwiftUI-подобного canvas в статус-баре. Системный шаблон ограничивает оформление, зато позволяет ОС адаптировать информацию к своему интерфейсу. Запрос на продвижение не равен успешному продвижению, а продвижение не доказывает, что человек посмотрел на уведомление.

Для команды это пять независимых вопросов: подходит ли задача; правильно ли составлено уведомление; разрешён ли показ; поддерживает ли его устройство; что действительно наблюдалось при проверке. Ни один из них нельзя заменить строкой «Android 16+» в техническом задании.

2. Какие задачи подходят, а какие требуют другого механизма

Хороший критерий — необходимость повторно проверять состояние прямо сейчас. Доставка еды и активная поездка имеют понятный конец и меняющийся ответ. Посылка, которая будет ехать неделю, обычно не требует постоянной карточки всю неделю. Оповещение о её прибытии остаётся полезным.

Обработка видео или AI-генерация не становятся подходящими Live Updates только из-за длительности. Начните с обычного состояния задачи и уведомления о результате. Если человек осознанно следит за коротким текущим процессом, оцените сценарий по правилам выбранного API. Не выдавайте придуманную плавную анимацию за измеренный прогресс.

Для регулярного входа в функцию рассмотрите виджет или Quick Settings tile. Для музыки — системную медиасессию. Для общения — conversation notifications и допустимые bubbles. Эти механизмы решают свои задачи и не требуют искусственно превращать всё в live-активность.

3. Версия ОС, AndroidX и оболочка — разные зависимости

ProgressStyle появился в Android 16. Но доступность стиля, системное продвижение и фирменный остров — разные возможности. Проверяйте runtime, QPR/сборку и прошивку производителя, а не только compileSdk.

В AndroidX методы setRequestPromotedOngoing и setShortCriticalText документированы с Core 1.17.0. Это не рекомендация вслепую обновить зависимости проекта: сначала посмотрите установленную версию, её требования и совместимость. Compat не добавляет старой ОС новую физическую поверхность.

4. Разрешения и канал уведомлений

В манифесте нужен обычный доступ к уведомлениям и отдельно декларация для продвижения:

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
<uses-permission android:name="android.permission.POST_PROMOTED_NOTIFICATIONS" />

На Android 13+ для большинства уведомлений требуется runtime-разрешение POST_NOTIFICATIONS. Запрашивайте его в понятном контексте: например, когда человек включает отслеживание заказа. Правила разрешения на уведомления описывают отказ и изменения при обновлении системы. POST_PROMOTED_NOTIFICATIONS не заменяет эту проверку и не является вторым обычным runtime-диалогом.

На Android 8+ создайте канал. Выбирайте важность по смыслу события. Нельзя повысить её программно поверх решения пользователя; уже существующий канал сохраняет пользовательские настройки. Для promoted-уведомления канал не должен иметь IMPORTANCE_MIN.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    val channel = NotificationChannel(
        "active_orders",
        "Текущие заказы",
        NotificationManager.IMPORTANCE_LOW
    )
    context.getSystemService(NotificationManager::class.java)
        .createNotificationChannel(channel)
}

Текст в примере фиксирован для краткости; в приложении его нужно локализовать. Создание канала не включает отключённые уведомления. Проверяйте настройки приложения и конкретного канала, а при недоступности сохраняйте рабочий экран заказа. Не переключайтесь незаметно на SMS, email или оверлей.

5. Минимальный Kotlin-пример и точный переход к заказу

Ниже — построение одного уведомления с AndroidX Core, содержащим нужные методы. snapshot — уже проверенное состояние заказа из приложения, openOrderPendingIntent открывает конкретный заказ, а значок является ресурсом проекта. Эти объекты нужно реализовать в существующей архитектуре.

val builder = NotificationCompat.Builder(context, "active_orders")
    .setSmallIcon(R.drawable.ic_delivery_status)
    .setContentTitle("Заказ в пути")
    .setContentText(snapshot.summary)
    .setShortCriticalText(
        snapshot.etaMinutes?.let { "$it мин" }
    )
    .setOngoing(true)
    .setRequestPromotedOngoing(true)
    .setOnlyAlertOnce(true)
    .setVisibility(NotificationCompat.VISIBILITY_PRIVATE)
    .setContentIntent(openOrderPendingIntent)

val notification = builder.build()

Фрагмент намеренно не придумывает «4 минуты», если ETA отсутствует. Для компактного текста нужен очень короткий ответ; отображаемую длину определяет система. setOnlyAlertOnce(true) помогает не сопровождать каждое изменение повторным сигналом, но важный переход «водитель ждёт» требует отдельного продуманного поведения.

Перед публикацией проверьте runtime-разрешение и доступность уведомлений. Затем обновляйте тот же экземпляр задачи через один стабильный идентификатор:

NotificationManagerCompat.from(context)
    .notify(snapshot.notificationId, notification)

notify здесь вызывается только после проверок. У разных заказов должны быть разные ID или пары tag + ID. Если все процессы используют один ID, новая поездка перезапишет старую. В соответствии с механизмом обновления уведомлений, повторная публикация с тем же идентификатором изменяет существующее уведомление.

Для PendingIntent используйте явное назначение, подходящие flags и идентичность конкретного объекта. Одних разных extras недостаточно, чтобы всегда получить разные PendingIntent. При переходе повторно проверяйте текущий аккаунт и право видеть заказ; ссылка не удостоверяет пользователя. Не отправляйте его на главный экран искать нужную поездку.

6. ProgressStyle: этапы и контрольные точки

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

Вариант AndroidX использует NotificationCompat.ProgressStyle. Его нужно сочетать с Compat Builder, а платформенный Notification.ProgressStyle — с соответствующим платформенным API. Не смешивайте два типа из похожих примеров.

val progressStyle = NotificationCompat.ProgressStyle()
    .setProgressSegments(listOf(
        NotificationCompat.ProgressStyle.Segment(20),
        NotificationCompat.ProgressStyle.Segment(30),
        NotificationCompat.ProgressStyle.Segment(50)
    ))
    .setProgress(measuredProgress)

// Применить до builder.build():
builder.setStyle(progressStyle)

В этом учебном примере три длины дают шкалу 100. Значение measuredProgress должно прийти из реальной модели и находиться в её диапазоне; цифры 20/30/50 показывают только устройство API. Если этапы известны, а доля выполнения — нет, покажите этап словами. Произвольное «65%» не делает прогноз точнее.

7. MetricStyle, таймеры и измеряемые значения

MetricStyle в Android 17 предназначен для измеряемых величин и поддерживает до трёх метрик и до трёх действий. В развёрнутом виде важны название, значение и единица; в свёрнутом часть метрик может не поместиться. Наиболее важную ставьте первой.

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

Системный секундомер или countdown предпочтительнее нового сетевого сообщения каждую секунду. Для обычных поддерживаемых уведомлений посмотрите setUsesChronometer(), setWhen() и режим обратного отсчёта; для MetricStyle — его актуальные средства времени. ETA курьера отличается от таймера: это прогноз, который нуждается в новых данных.

8. Как понять, что продвижение действительно доступно

Проверки выполняются только на версиях, где доступны соответствующие символы. Для перехода к настройкам предусмотрен Settings.ACTION_MANAGE_APP_PROMOTED_NOTIFICATIONS; сначала объясните пользу и проверьте, что intent поддерживается. Не открывайте настройки повторно после каждого отказа.

Неуспешное продвижение само по себе не означает, что заказ перестал выполняться или данные потеряны. Это состояние представления. Основной пользовательский процесс должен оставаться понятным без капсулы. Для аналитики разделяйте созданное уведомление, разрешённое продвижение, наблюдаемый системный флаг и действие человека.

9. Фоновые обновления, свежесть и завершение

Notification API не держит приложение работающим. Серверный транспорт, выполнение фоновой работы и отображение уведомления — отдельные механизмы. FCM или OEM push должны доставить событие, код — обработать его в разрешённом контексте, а адаптер — отразить актуальное состояние. Успешная отправка с сервера не доказывает, что карточка уже обновилась.

Foreground service подходит только для соответствующей пользовательской работы и допустимого типа сервиса. Его нельзя добавлять исключительно ради постоянного островка. Google отдельно описывает ограничения запуска foreground services из фона. WorkManager тоже не является ежесекундным real-time каналом.

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

Заранее решите, что означает отсутствие данных. Можно показывать последний известный этап с отметкой времени, убрать недостоверный ETA или завершить live-представление по правилам продукта. Это явное проектное решение; нельзя молча заменить неизвестное нулём или бесконечно продлевать обещание «через минуту».

При завершении прекратите текущие обновления. Если нужен итог, опубликуйте спроектированное финальное состояние; если нет — удалите уведомление через cancel. Пользовательское скрытие не отменяет заказ. Поведение удаления ongoing-уведомлений различается между версиями — проверяйте его, а не принудительно возвращайте карточку ради внимания.

10. Samsung, Xiaomi, OPPO и другие: отдельные условия подключения

В таблице «публичный API» означает документированный механизм разработки. «OEM-путь» — отдельный канал производителя, который может требовать допуска. «Функция устройства» подтверждает пользовательскую возможность, но не наличие SDK для любого приложения. Это разные уровни доказательности.

Samsung: Now Bar нужно проверять как отдельное представление

Samsung описывает Now Bar прежде всего как поверхность на экране блокировки для поддерживаемых активностей. В настройках человек выбирает приложения; нужны также разрешённые уведомления и показ на блокировке. Поэтому «система новая, значит наше приложение точно появится» — слабое техническое основание. В инструкции Samsung по настройке Now Bar есть и список необходимых переключателей, и диагностика отсутствующего содержимого.

Для медиапродукта сначала имеет смысл корректно реализовать системное воспроизведение. Для доставки — проверить стандартные Live Updates. Прямое управление произвольным содержимым Now Bar не следует обещать, пока не найден подходящий документированный путь именно для вашего приложения.

Xiaomi: выразительный интерфейс и отдельная процедура подключения

Xiaomi предлагает Super Island с несколькими островами, раскрытием, переходом в небольшое окно и передачей содержимого перетаскиванием. Официальный процесс включает регистрацию приложения, запрос услуги, согласование сценария и тестирование. Документация также описывает MiPush как способ доставки сообщений при неработающем процессе приложения.

Важно, что критерии Xiaomi не тождественны Google. В правилах допуска Super Island указан конечный жизненный цикл до 12 часов и запрет маркетинговых сценариев; некоторые категории обслуживаются системно и не открыты для дублирующего подключения. Для Global/EEA нельзя автоматически переносить условия китайского портала: доступ к программе и поведение международной прошивки необходимо подтвердить отдельно.

OPPO, OnePlus и realme: похожие названия не означают общий контракт

У OPPO есть фирменный путь Fluid Cloud. Например, руководство Alibaba Cloud EMAS по обновлению Fluid Cloud описывает подготовку, согласование с OPPO и серверные операции. Это доказательство возможностей данного интеграционного канала, а не универсального доступа для каждого APK в любом регионе.

OnePlus показывает Fluid Cloud в OxygenOS 16 для музыки, спорта, дорожной информации и доставки. Но продуктовая презентация не заменяет спецификацию интеграции. У realme C75 Mini Capsule 3.0 демонстрирует статус Grab; поддержка этого сервиса не доказывает, что аналогично подключается любое стороннее приложение. Даже в близких экосистемах матрица совместимости остаётся отдельной.

vivo и HONOR: проектируется сценарий, а не произвольный баннер

У vivo атомные уведомления предусматривают создание, изменение и окончание активности. Описание интеграции Origin Island через EMAS показывает шаблоны для капсулы, карточек и блокировки, локальные операции и серверный push; доступ нужно запросить. Страница помечает функцию этого канала как публичное тестирование. Численные лимиты частоты и длительности фиксируйте из актуального договора конкретного канала, а не из общей таблицы Android.

HONOR рассматривает Magic Capsule как один из входов Magic Live и YOYO, наряду с рекомендациями, AOD и другими представлениями. Это полезно для сервисов с понятным текущим намерением: поездки, бронирования, получения заказа. Однако наличие капсулы в системе не даёт приложению права постоянно занимать её; точный путь и условия доступа необходимо подтвердить в программе производителя.

Huawei: название устройства не определяет стек разработки

Пользовательская Live View у Huawei включает компактную капсулу и раскрывающуюся карточку текущей задачи. Для HarmonyOS NEXT существует отдельный Live View Kit. Его нельзя рассматривать как ещё одну Android-библиотеку: нативная HarmonyOS требует своей реализации. Условия конкретной версии Kit также нельзя переносить на весь парк Huawei.

Nothing: корпус становится интерфейсом

Для Glyph Interface опубликован developer kit, но его документация ограничивает использование foreground-приложениями. Это существенно: нельзя обещать фоновый индикатор доставки, посмотрев только эффектную демонстрацию светодиодов.

Glyph Matrix имеет свой набор интерфейсов и Glyph Toys. В таблице поддержки Phone (3) и Phone (4a) Pro отличаются размером матрицы и возможностями взаимодействия. Проверяйте аппаратные возможности во время выполнения, приоритеты отображения и условия использования SDK. Сам факт публичного репозитория не заменяет такую проверку.

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

TECNO, Infinix и длинный хвост устройств

Производители демонстрируют Dynamic Port в HiOS и Magic Ring у Infinix. В рамках этого исследования универсальный публичный путь создания собственных капсул для этих механизмов не подтверждён. Это не утверждение, что интеграция невозможна; это причина не продавать её как уже обеспеченную функцию проекта.

Светодиодные панели и задние дисплеи требуют отдельной классификации. Руководство по вторым экранам разбирает Glyph Matrix, обычное приложение на Ulefone, Presentation и WindowManager. Допуск в HyperIsland не означает разрешение рисовать на задней панели Xiaomi.

11. Архитектура: одна задача, несколько адаптеров

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

Для OEM-адаптера зафиксируйте: рынок и сборку, идентификатор приложения, согласованный сценарий, схему payload, допустимые действия, transport, правила обновления и окончания. Значения Notification.extras берите из официальной спецификации, а не из догадки по виду капсулы. Подключённая библиотека без допуска и проверенного payload ещё не означает интеграцию.

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

12. Приватность и доступность

Проектируйте публичную версию содержимого для блокировки. VISIBILITY_PUBLIC, PRIVATE, SECRET и подходящая public version помогают управлять раскрытием, но результат зависит также от настроек пользователя и системы. Подробности есть в руководстве по уведомлениям Android.

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

Проверьте TalkBack, крупный шрифт, RTL, длинные переводы, контраст, блокировку и AOD. Цвет участка прогресса должен дополнять понятный текст. Короткое число без единицы может оказаться бессмысленным, когда ОС уберёт второстепенные подписи.

13. Матрица проверки перед выпуском

Для каждого результата записывайте устройство, версию/сборку ОС, регион прошивки, версию приложения и настройки. «Проверено на Android» — слишком неопределённая запись. Эмулятор полезен для общей реализации, но не доказывает поведение Now Bar или HyperIsland на реальном телефоне.

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

Применить руководство с Codex и Claude Code

По результатам этого исследования мы создали скилл Interaction Surfaces для Codex и Claude Code и скилл Adaptive Interfaces. Они помогают проанализировать существующий сайт или приложение, определить доступные API и предложить полезные сценарии: виджеты, текущие активности, часы, дополнительные экраны и адаптацию интерфейса. Вы выбираете, что внедрить, отложить или исключить; затем агент реализует выбранные изменения и проверяет результат в пределах доступных платформ и устройств.

Для работы над своим приложением можно установить скилл Interaction Surfaces из GitHub. В нём есть Kotlin-пример, разрешения и диагностика Live Updates, OEM-интеграции и отдельное руководство по Wear OS. Английский пакет охватывает всю серию; инструкция по установке и пример вызова находятся в общем обзоре.

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

Можно ли сделать один универсальный остров для всех Android?

Можно использовать общую модель данных и стандартные API, но нельзя гарантировать одинаковую оболочку, положение, действия и допуск на каждом устройстве. OEM-пути подключаются отдельно.

Если уведомление создано, почему нет капсулы?

Проверьте критерии сценария, свойства уведомления, канал, настройки продвижения, runtime и условия производителя. Сам вызов notify не обещает promoted-представление.

Нужно ли использовать SYSTEM_ALERT_WINDOW?

Для системного Live Update — нет. Собственный оверлей является другим типом окна со специальным разрешением и ограничениями. Он не заменяет нативную интеграцию статус-бара.

Подходит ли стандартное уведомление старым устройствам?

Это самостоятельный поддерживаемый путь, который нужно спроектировать и проверить для целевых версий. Не обещайте новые системные представления на основании одной лишь библиотеки Compat.