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, електронну пошту або оверлей.

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.