App Standby — co to je, úrovně čekání a princip fungování

Co je App Standby

App Standby je součást systému správy energie Androidu, zavedená v Android 6.0 (API 23) a výrazně přepracovaná v Android 9 (API 28). Jejím úkolem je určit, které aplikace uživatel používá zřídka, a omezit jejich aktivitu na pozadí: síťové požadavky, synchronizaci, JobScheduler a AlarmManager. Na rozdíl od Doze, App Standby nezávisí na stavu obrazovky nebo pohybu zařízení.

Systém klasifikuje aplikace do čtyř bucketů (úrovní): Active, Working Set, Frequent a Rare. Každá úroveň určuje, jak moc je aktivita na pozadí omezena. Přechod mezi úrovněmi probíhá automaticky na základě vzorců používání aplikace: jak často ji uživatel otevírá, dostává oznámení, interaguje s widgety.

App Standby pracuje společně s Doze Mode, ale nenahrazuje jej. Pokud Doze omezuje aktivitu na pozadí všech aplikací při nečinnosti zařízení, App Standby omezuje konkrétní aplikace nezávisle na stavu zařízení. Aplikace s úrovní Rare bude mít omezení i při aktivním používání telefonu, pokud ji uživatel několik dní neotevřel.

Bucket v Android 9+

Od Android 9 (API 28) společnost Google zavedla App Standby Buckets — formální klasifikaci s číselnými hodnotami. Systém používá strojové učení k predikci dalšího spuštění aplikace. Pokud model předpovídá, že aplikace bude otevřena v následujících hodinách, obdrží bucket Active. Pokud predikce ukazuje na vzácné používání — je přiřazen Rare.

Jak funguje App Standby

App Standby analyzuje několik faktorů pro určení bucketu: čas od posledního otevření aplikace uživatelem, frekvenci interakce (počet spuštění za den/týden), příjem FCM oznámení, přítomnost aktivních widgetů na ploše a předplatné AlarmManageru. Čím déle se aplikace nepoužívá, tím nižší je její bucket a tím přísnější jsou omezení.

Systémová služba UsageStatsManager shromažďuje statistiky používání aplikací a předává je StandbyControlleru — součásti frameworku, která vypočítává bucket pro každou aplikaci. StandbyController také zohledňuje systémové události: po aktualizaci aplikace se její bucket na několik dní resetuje na Active, aby uživatel mohl vyhodnotit nové funkce.

Důležitá vlastnost: App Standby nezabíjí proces aplikace, ale omezuje její možnosti na pozadí. Aplikace nadále funguje, pokud s ní uživatel interaguje (bucket Active). Jakmile uživatel aplikaci minimalizuje a nevrátí se k ní, systém začne počítat dobu nečinnosti a může snížit bucket na Working Set nebo Frequent.

Vliv FCM na bucket

Příjem zprávy FCM high-priority může dočasně zvýšit bucket aplikace na Active. To dává aplikaci možnost provést úlohu (zpracovat zprávu, synchronizovat data) bez omezení. Po dokončení zpracování se však bucket vrací na původní hodnotu. Google doporučuje používat tento mechanismus pro doručování důležitých oznámení, nikoli pro udržování aplikace “naživu”.

Úrovně App Standby

App Standby používá čtyři úrovně (bucket) pro klasifikaci aplikací. Každá úroveň určuje dobu zpoždění pro úlohy na pozadí: čím nižší úroveň, tím delší zpoždění. Systém automaticky přesouvá aplikaci mezi úrovněmi na základě statistik používání shromážděných za posledních 7–14 dní.

Active — aktivní aplikace

Active — aplikace, se kterou uživatel nedávno interagoval (spustil, obdržel oznámení nebo použil widget). V tomto bucketu nejsou žádná omezení: JobScheduler se spouští okamžitě, síť je k dispozici, AlarmManager funguje přesně. Aplikace zůstává v Active, dokud uživatel nepřestane s ní interagovat po dobu několika hodin.

Working Set a Frequent

Working Set — aplikace je používána pravidelně (několikrát týdně). Zpoždění úloh na pozadí až 2 hodiny. Frequent — aplikace je používána několikrát měsíčně. Zpoždění až 4 hodiny. Na obou úrovních je síť k dispozici pouze v oknech údržby a AlarmManager může být zpožděn. JobScheduler provádí úlohy v nejbližším okně.

Rare — zřídka používaná

Rare — nejpřísnější úroveň, přiřazená aplikacím, které uživatel neotevřel déle než 30 dní. Zpoždění úloh na pozadí dosahuje 24 hodin. Síť je zcela blokována mimo okna údržby, AlarmManager funguje pouze s příznaky setAndAllowWhileIdle() s omezením 1krát za 9 minut. Oznámení FCM high-priority jsou stále doručována, ale nemohou zvýšit bucket.

Omezení v App Standby

App Standby ukládá omezení na několik kategorií operací na pozadí. Na rozdíl od Doze, omezení App Standby fungují nezávisle na stavu obrazovky a nabíječky. Vývojář by měl navrhovat aplikaci s ohledem na tato omezení, zejména pokud cílová skupina používá aplikaci nepravidelně.

JobScheduler a WorkManager

JobScheduler — hlavní API, na které App Standby působí. V závislosti na bucketu se zpoždění provádění úloh pohybuje od 2 do 24 hodin. WorkManager, který používá JobScheduler pod kapotou (na API 23+), rovněž podléhá těmto zpožděním. Pro časově kritické úlohy použijte Expedited Work, který spouští Foreground Service pod kapotou a nezávisí na bucketu.

Síťová omezení

Aplikace v bucketu Working Set, Frequent a Rare nemohou provádět libovolné síťové požadavky kdykoli. Systém povoluje přístup k síti pouze v oknech údržby synchronizovaných s Doze. Pro odesílání kritických dat použijte FCM high-priority s následnou synchronizací v okně údržby.

AlarmManager

AlarmManager v App Standby podléhá stejným pravidlům jako v Doze: přesné budíky (setExact()) jsou zpožděny a setAndAllowWhileIdle() je omezen na 1 spuštění za 9 minut. Pro bucket Rare může zpoždění dosáhnout 24 hodin, což činí AlarmManager nevhodným pro přesné plánování úloh ve zřídka používaných aplikacích.

• JobScheduler — úlohy jsou zpožděny 2–24 hodin v závislosti na bucketu
• Síť — přístup pouze v oknech údržby pro Working Set a nižší
• AlarmManager — přesné budíky jsou zpožděny; setAndAllowWhileIdle — 1/9 min
• SyncManager — synchronizace účtů je zpožděna do okna údržby
• Widget updates — frekvence aktualizace widgetů může být snížena

Jak získat výjimku

Výjimku z App Standby lze získat dvěma způsoby: prostřednictvím uživatelských nastavení baterie (ruční Whitelist) nebo prostřednictvím systémového Intentu ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Google však přísně reguluje přístup k výjimkám — aplikace, které nemají závažný důvod pro výjimku, riskují zamítnutí v Obchodě Google Play.

Uživatel může ručně zakázat omezení pro konkrétní aplikaci prostřednictvím Nastavení → Aplikace → [Aplikace] → Baterie → Optimalizace → Neoptimalizovat. To zcela odstraní omezení App Standby a Doze pro vybranou aplikaci. Vývojář může uživateli zobrazit instrukci nebo systémový dialog, ale nemůže aplikaci násilně přidat do výjimek.

Foreground Service s oznámením automaticky získává dočasnou výjimku z App Standby. Dokud služba běží a zobrazuje oznámení, je aplikace převedena do bucketu Active bez ohledu na její skutečnou úroveň. Po zastavení služby se bucket vrací na původní hodnotu. Toto je nejspolehlivější způsob, jak zaručit práci na pozadí bez žádání o systémové výjimky.

Kdy žádat o výjimku

Žádost o Whitelist má smysl pouze pro aplikace s kriticky důležitou funkcionalitou na pozadí: navigace v reálném čase, monitorování zdraví, VoIP hovory, ochrana zařízení. Pro většinu aplikací stačí použít Foreground Service nebo WorkManager. Google Play může odmítnout publikaci, pokud aplikace žádá o výjimku bez zjevné potřeby.

// Žádost o výjimku z App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Kontrola aktuálního stavu
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Testování App Standby

Testování App Standby přes ADB umožňuje násilně přiřadit aplikaci libovolný bucket a zkontrolovat její chování. To je kritické pro aplikace, které spoléhají na synchronizaci na pozadí, oznámení nebo pravidelné aktualizace. Testování by mělo být prováděno na fyzickém zařízení nebo emulátoru s Android 9+.

Pro násilné nastavení bucketu se používá příkaz adb shell am set-standby-bucket [package] [bucket], kde bucket může být: active, working_set, frequent nebo rare. Pro zobrazení aktuálního bucketu — adb shell am get-standby-bucket [package]. Systém také umožňuje simulaci dlouhodobé nečinnosti aplikace pomocí příkazu adb shell dumpsys usagestats.

# Nastavení bucketu Rare pro aplikaci
$ adb shell am set-standby-bucket com.example.app rare

# Zobrazení aktuálního bucketu
$ adb shell am get-standby-bucket com.example.app

# Reset všech bucketů na Active
$ adb shell dumpsys usagestats clear

# Zobrazení všech bucketů systému
$ adb shell dumpsys usagestats

Co zkontrolovat

Po nastavení bucketu Rare zkontrolujte: zda se úloha WorkManager provádí do 24 hodin, zda se AlarmManager spouští, zda jsou oznámení FCM doručována, zda Foreground Service funguje bez omezení. WorkManager s politikou Expedited Work by se měl provést okamžitě i v bucketu Rare, protože používá Foreground Service. Běžné úlohy WorkManager budou zpožděny podle bucketu.

Nejlepší postupy

Vývoj aplikace odolné vůči App Standby vyžaduje vědomý přístup k úlohám na pozadí. Základní princip: nepředpokládejte, že aplikace je vždy v bucketu Active. Navrhněte práci na pozadí tak, aby správně fungovala se zpožděními charakteristickými pro bucket Frequent a Rare.

Používejte WorkManager s Expedited Work

Expedited Work (WorkManager 2.7+) spouští Foreground Service pod kapotou, což dává úloze okamžité provedení nezávisle na bucketu. To je optimální volba pro úlohy, které nelze zpozdit: odeslání zprávy, synchronizace po platbě, zpracování příchozího hovoru. Běžné úlohy WorkManager se provádějí v oknech údržby s ohledem na bucket.

FCM pro reaktivaci

Používejte zprávy FCM high-priority k probuzení aplikace z App Standby. Když aplikace obdrží takovou zprávu, její bucket se dočasně zvýší na Active a může provést potřebné úlohy (synchronizace, aktualizace dat). Po dokončení zpracování se bucket vrací na původní úroveň.

Vyhněte se trvalému udržování v paměti

Nepokoušejte se obejít App Standby pomocí trvalých služeb na pozadí, WakeLock nebo pravidelných FCM zpráv. Google aktivně bojuje proti takovým praktikám — aplikace může být označena jako energeticky náročná a omezena ještě přísněji. Používejte WorkManager pro pravidelné úlohy a Foreground Service pouze tehdy, když je úloha skutečně viditelná pro uživatele.

• WorkManager — preferované API; Expedited Work provádí úlohy bez zpoždění
• FCM high-priority — dočasně zvyšuje bucket na Active pro zpracování zprávy
• Neobcházejte App Standby — to vede k blokování aplikace systémem
• Foreground Service — dočasně převádí aplikaci do Active po dobu běhu
• Testujte aplikaci v bucketech Rare a Frequent přes ADB před každým vydáním