App Standby — що це, рівні очікування та принцип роботи

Що таке App Standby

App Standby — це компонент системи управління енергоспоживанням Android, введений в Android 6.0 (API 23) і значно перероблений в Android 9 (API 28). Його завдання — визначити, які додатки користувач використовує рідко, і обмежити їх фонову активність: мережеві запити, синхронізацію, JobScheduler та AlarmManager. На відміну від Doze, App Standby не залежить від стану екрана або руху пристрою.

Система класифікує додатки за чотирма bucket (рівнями): Active, Working Set, Frequent і Rare. Кожен рівень визначає, наскільки сильно обмежується фонова активність. Перехід між рівнями відбувається автоматично на основі патернів використання додатка: як часто користувач відкриває його, отримує сповіщення, взаємодіє з віджетами.

App Standby працює в парі з Doze Mode, але не замінює його. Якщо Doze обмежує фонову активність всіх додатків при бездіяльності пристрою, то App Standby обмежує конкретні додатки незалежно від стану пристрою. Додаток з рівнем Rare матиме обмеження навіть при активному використанні телефона, якщо користувач не відкривав його кілька днів.

Bucket в Android 9+

Починаючи з Android 9 (API 28), Google ввів App Standby Buckets — формальну класифікацію з числовими значеннями. Система використовує машинне навчання для передбачення наступного запуску додатка. Якщо модель передбачає, що додаток буде відкрито найближчими годинами, він отримує bucket Active. Якщо передбачення вказує на рідкісне використання — призначається Rare.

Як працює App Standby

App Standby аналізує кілька факторів для визначення bucket: час з останнього відкриття додатка користувачем, частота взаємодії (кількість запусків на день/тиждень), отримання FCM-повідомлень, наявність активних віджетів на робочому столі та підписка на AlarmManager. Чим довше додаток не використовується, тим нижчий його bucket і тим суворіші обмеження.

Системний сервіс UsageStatsManager збирає статистику використання додатків і передає її в StandbyController — компонент framework, який розраховує bucket для кожного додатка. StandbyController також враховує системні події: після оновлення додатка його bucket скидається до Active на кілька днів, щоб користувач міг оцінити нові функції.

Важлива особливість: App Standby не вбиває процес додатка, а обмежує його фонові можливості. Додаток продовжує працювати, якщо користувач взаємодіє з ним (bucket Active). Як тільки користувач згортає додаток і не повертається до нього, система починає відлік часу бездіяльності і може знизити bucket до Working Set або Frequent.

Вплив FCM на bucket

Отримання FCM high-priority повідомлення може тимчасово підвищити bucket додатка до Active. Це дає додатку можливість виконати завдання (обробити повідомлення, синхронізувати дані) без обмежень. Однак після завершення обробки bucket повертається до вихідного значення. Google рекомендує використовувати цей механізм для доставки важливих сповіщень, а не для підтримання додатка «в живих».

Рівні App Standby

App Standby використовує чотири рівні (bucket) для класифікації додатків. Кожен рівень визначає час затримки для фонових завдань: чим нижчий рівень, тим довша затримка. Система автоматично переміщує додаток між рівнями на основі статистики використання, зібраної за останні 7–14 днів.

Active — активний додаток

Active — додаток, з яким користувач взаємодіяв нещодавно (запускав, отримував сповіщення або використовував віджет). У цьому bucket немає обмежень: JobScheduler запускається негайно, мережа доступна, AlarmManager спрацьовує точно. Додаток залишається в Active до тих пір, поки користувач не перестане з ним взаємодіяти на кілька годин.

Working Set і Frequent

Working Set — додаток використовується регулярно (кілька разів на тиждень). Затримка фонових завдань до 2 годин. Frequent — додаток використовується кілька разів на місяць. Затримка до 4 годин. В обох рівнях мережа доступна тільки у вікнах обслуговування, а AlarmManager може бути відкладений. JobScheduler виконує завдання в найближче вікно.

Rare — рідко використовуваний

Rare — найсуворіший рівень, який призначається додаткам, які користувач не відкривав більше 30 днів. Затримка фонових завдань досягає 24 годин. Мережа повністю блокується поза вікнами обслуговування, AlarmManager спрацьовує тільки з прапорцями setAndAllowWhileIdle() з обмеженням 1 раз на 9 хвилин. FCM high-priority повідомлення, як і раніше, доставляються, але не можуть підвищити bucket.

Обмеження в App Standby

App Standby накладає обмеження на кілька категорій фонових операцій. На відміну від Doze, обмеження App Standby діють незалежно від стану екрана та зарядного пристрою. Розробник повинен проектувати додаток з урахуванням цих обмежень, особливо якщо цільова аудиторія використовує додаток нерегулярно.

JobScheduler і WorkManager

JobScheduler — основний API, на який впливає App Standby. Залежно від bucket затримка виконання завдань становить від 2 до 24 годин. WorkManager, який використовує JobScheduler під капотом (на API 23+), також піддається цим затримкам. Для критичних за часом завдань використовуйте Expedited Work, який запускає Foreground Service під капотом і не залежить від bucket.

Мережеві обмеження

Додатки в bucket Working Set, Frequent і Rare не можуть виконувати довільні мережеві запити в будь-який час. Система дозволяє доступ до мережі тільки у вікнах обслуговування, які синхронізовані з Doze. Для відправки критичних даних використовуйте FCM high-priority з подальшою синхронізацією у вікні обслуговування.

AlarmManager

AlarmManager в App Standby підпорядковується тим же правилам, що і в Doze: точні будильники (setExact()) відкладаються, а setAndAllowWhileIdle() обмежений 1 спрацьовуванням за 9 хвилин. Для bucket Rare затримка може досягати 24 годин, що робить AlarmManager непридатним для точного планування завдань у рідко використовуваних додатках.

• JobScheduler — завдання відкладаються на 2–24 години залежно від bucket
• Мережа — доступ тільки у вікнах обслуговування для Working Set і нижче
• AlarmManager — точні будильники відкладаються; setAndAllowWhileIdle — 1/9 хв
• SyncManager — синхронізація облікових записів затримується до вікна обслуговування
• Widget updates — частота оновлення віджетів може бути знижена

Як отримати виняток

Виняток з App Standby можна отримати двома способами: через користувацькі налаштування батареї (ручний Whitelist) або через системний Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Однак Google суворо регулює доступ до винятків — додатки, які не мають вагомої причини для винятку, ризикують бути відхиленими в Google Play.

Користувач може вручну вимкнути обмеження для конкретного додатка через Налаштування → Додатки → [Додаток] → Батарея → Оптимізація → Не оптимізувати. Це повністю знімає обмеження App Standby і Doze для вибраного додатка. Розробник може показати користувачеві інструкцію або системний діалог, але не може примусово додати додаток до винятків.

Foreground Service з повідомленням автоматично отримує тимчасовий виняток з App Standby. Поки сервіс працює і відображає сповіщення, додаток переводиться в bucket Active незалежно від його реального рівня. Після зупинки сервісу bucket повертається до вихідного значення. Це найнадійніший спосіб гарантувати фонову роботу без запиту системних винятків.

Коли запитувати виняток

Запитувати Whitelist має сенс тільки для додатків з критично важливою фоновою функціональністю: навігація в реальному часі, моніторинг здоров'я, VoIP-дзвінки, захист пристрою. Для більшості додатків достатньо використовувати Foreground Service або WorkManager. Google Play може відхилити публікацію, якщо додаток запитує виняток без очевидної необхідності.

// Запит винятку з App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Перевірка поточного статусу
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Тестування App Standby

Тестування App Standby через ADB дозволяє примусово призначити додатку будь-який bucket і перевірити його поведінку. Це критично важливо для додатків, які покладаються на фонову синхронізацію, сповіщення або періодичні оновлення. Тестування необхідно проводити на фізичному пристрої або емуляторі з Android 9+.

Для примусового встановлення bucket використовується команда adb shell am set-standby-bucket [package] [bucket], де bucket може бути: active, working_set, frequent або rare. Для перегляду поточного bucket — adb shell am get-standby-bucket [package]. Система також дозволяє симулювати тривалу бездіяльність додатка через команду adb shell dumpsys usagestats.

# Встановлення bucket Rare для додатка
$ adb shell am set-standby-bucket com.example.app rare

# Перегляд поточного bucket
$ adb shell am get-standby-bucket com.example.app

# Скидання всіх bucket до Active
$ adb shell dumpsys usagestats clear

# Перегляд всіх bucket системи
$ adb shell dumpsys usagestats

Що перевіряти

Після встановлення bucket Rare перевірте: чи виконується WorkManager-завдання протягом 24 годин, чи спрацьовує AlarmManager, чи доставляються FCM-повідомлення, чи працює Foreground Service без обмежень. WorkManager з політикою Expedited Work повинен виконуватися негайно навіть у bucket Rare, оскільки використовує Foreground Service. Звичайні завдання WorkManager будуть відкладені відповідно до bucket.

Найкращі практики

Розробка додатка, стійкого до App Standby, вимагає усвідомленого підходу до фонових завдань. Основний принцип: не припускати, що додаток завжди знаходиться в bucket Active. Проектуйте фонову роботу так, щоб вона коректно виконувалася з затримками, характерними для bucket Frequent і Rare.

Використовуйте WorkManager з Expedited Work

Expedited Work (WorkManager 2.7+) запускає Foreground Service під капотом, що дає завданню негайне виконання незалежно від bucket. Це оптимальний вибір для завдань, які не можуть бути відкладені: відправка повідомлення, синхронізація після оплати, обробка вхідного виклику. Звичайні завдання WorkManager виконуються у вікнах обслуговування з урахуванням bucket.

FCM для реактивації

Використовуйте FCM high-priority повідомлення для пробудження додатка з App Standby. Коли додаток отримує таке повідомлення, його bucket тимчасово підвищується до Active, і він може виконати необхідні завдання (синхронізація, оновлення даних). Після завершення обробки bucket повертається до вихідного рівня.

Уникайте постійного утримання в пам'яті

Не намагайтеся обійти App Standby за допомогою постійних фонових сервісів, WakeLock або періодичних FCM-повідомлень. Google активно бореться з такими практиками — додаток може бути позначений як енергозатратний і обмежений ще суворіше. Використовуйте WorkManager для періодичних завдань і Foreground Service тільки коли завдання дійсно видиме користувачеві.

• WorkManager — кращий API; Expedited Work виконує завдання без затримки
• FCM high-priority — тимчасово підвищує bucket до Active для обробки повідомлення
• Не обходь App Standby — це призводить до блокування додатка системою
• Foreground Service — тимчасово переводить додаток в Active на час роботи
• Тестуй додаток в bucket Rare і Frequent через ADB перед кожним релізом