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. Всяко ниво определя колко е ограничена фоновата активност. Преходът между нивата се извършва автоматично въз основа на моделите на използване на приложението: колко често потребителят го отваря, получава известия, взаимодейства с widget-и.

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 известия, наличие на активни widget-и на работния плот и абонамент за 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 — приложението, с което потребителят наскоро е взаимодействал (стартирал, получил известие или използвал widget). В този 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 min
• SyncManager — синхронизацията на акаунти се забавя до прозореца за обслужване
• Widget updates — честотата на актуализация на widget-ите може да бъде намалена

Как да получите изключение

Изключение от 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 преди всяко издание