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-у — компоненти оквира која израчунава bucket за сваку апликацију. StandbyController такође узима у обзир системске догађаје: након ажурирања апликације, њен bucket се ресетује на Active на неколико дана како би корисник могао да оцени нове функције.

Важна карактеристика: App Standby не убија процес апликације, већ ограничава њене позадинске могућности. Апликација наставља да ради ако корисник интерагује са њом (bucket Active). Чим корисник minimizuje апликацију и не врати јој се, систем почиње да броји време неактивности и може спустити 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 min
• 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-а пре сваког издања