App Standby — mi ez, várakozási szintek és működési elv

Mi az App Standby

App Standby az Android energia-gazdálkodási rendszerének egy összetevője, amelyet Android 6.0 (API 23) vezetett be, és jelentősen átdolgozták Android 9 (API 28) rendszerben. Feladata annak meghatározása, hogy mely alkalmazásokat használja a felhasználó ritkán, és ezek háttértevékenységének korlátozása: hálózati kérések, szinkronizálás, JobScheduler és AlarmManager. Ellentétben a Doze-zal, az App Standby nem függ a képernyő állapotától vagy az eszköz mozgásától.

A rendszer négy bucket-be (szintbe) sorolja az alkalmazásokat: Active, Working Set, Frequent és Rare. Minden szint meghatározza, hogy mennyire korlátozott a háttértevékenység. A szintek közötti átmenet automatikusan történik az alkalmazás használati mintái alapján: milyen gyakran nyitja meg a felhasználó, kap értesítéseket, lép kapcsolatba widget-ekkel.

Az App Standby a Doze Mode-dal párhuzamosan működik, de nem helyettesíti azt. Ha a Doze az eszköz inaktivitásakor az összes alkalmazás háttértevékenységét korlátozza, akkor az App Standby meghatározott alkalmazásokat korlátoz az eszköz állapotától függetlenül. A Rare szintű alkalmazás még aktív telefonhasználat mellett is korlátozásokkal rendelkezik, ha a felhasználó napok óta nem nyitotta meg.

Bucket Android 9+ rendszerben

Android 9 (API 28) rendszertől kezdve a Google bevezette az App Standby Buckets-eket — egy formális osztályozást numerikus értékekkel. A rendszer gépi tanulást használ az alkalmazás következő indításának előrejelzésére. Ha a modell azt jósolja, hogy az alkalmazás a következő órákban megnyílik, Active bucket-ot kap. Ha az előrejelzés ritka használatot jelez — Rare kerül hozzárendelésre.

Hogyan működik az App Standby

App Standby több tényezőt elemez a bucket meghatározásához: az alkalmazás utolsó megnyitása óta eltelt idő, az interakció gyakorisága (napi/heti indítások száma), FCM-értesítések fogadása, aktív widget-ek jelenléte a kezdőképernyőn és AlarmManager előfizetés. Minél tovább nem használják az alkalmazást, annál alacsonyabb a bucket-je és annál szigorúbbak a korlátozások.

A rendszerszolgáltatás UsageStatsManager összegyűjti az alkalmazások használati statisztikáit, és továbbítja azokat a StandbyController-nek — a keretrendszer egy összetevőjének, amely kiszámítja a bucket-et minden alkalmazáshoz. A StandbyController figyelembe veszi a rendszereseményeket is: az alkalmazás frissítése után a bucket néhány napra visszaáll Active értékre, hogy a felhasználó értékelhesse az új funkciókat.

Fontos jellemző: App Standby nem öli meg az alkalmazás folyamatát, hanem korlátozza a háttérbeli képességeit. Az alkalmazás tovább működik, ha a felhasználó kapcsolatba lép vele (bucket Active). Amint a felhasználó minimalizálja az alkalmazást és nem tér vissza hozzá, a rendszer elkezdi számolni az inaktivitási időt, és csökkentheti a bucket-et Working Set vagy Frequent értékre.

Az FCM hatása a bucket-re

Egy FCM high-priority üzenet fogadása ideiglenesen Active-ra emelheti az alkalmazás bucket-jét. Ez lehetőséget ad az alkalmazásnak egy feladat korlátozás nélküli végrehajtására (üzenet feldolgozása, adatok szinkronizálása). A feldolgozás befejezése után azonban a bucket visszatér az eredeti értékre. A Google azt ajánlja, hogy ezt a mechanizmust fontos értesítések kézbesítésére használják, ne az alkalmazás „életben”tartására.

App Standby szintek

App Standby négy szintet (bucket) használ az alkalmazások osztályozására. Minden szint meghatározza a háttérfeladatok késleltetési idejét: minél alacsonyabb a szint, annál hosszabb a késleltetés. A rendszer automatikusan mozgatja az alkalmazást a szintek között az elmúlt 7–14 napban gyűjtött használati statisztikák alapján.

Active — aktív alkalmazás

Active — az alkalmazás, amellyel a felhasználó nemrég kapcsolatba lépett (elindította, értesítést kapott vagy widget-et használt). Ebben a bucket-ben nincsenek korlátozások: a JobScheduler azonnal elindul, a hálózat elérhető, az AlarmManager pontosan működik. Az alkalmazás Active-ban marad, amíg a felhasználó néhány órára abbahagyja a vele való interakciót.

Working Set és Frequent

Working Set — az alkalmazást rendszeresen használják (hetente többször). A háttérfeladatok késleltetése akár 2 óra. Frequent — az alkalmazást havonta többször használják. Késleltetés akár 4 óra. Mindkét szinten a hálózat csak szolgáltatási ablakokban érhető el, és az AlarmManager késleltethető. A JobScheduler a legközelebbi ablakban hajtja végre a feladatokat.

Rare — ritkán használt

Rare — a legszigorúbb szint, azon alkalmazásokhoz rendelve, amelyeket a felhasználó több mint 30 napja nem nyitott meg. A háttérfeladatok késleltetése eléri a 24 órát. A hálózat teljesen blokkolva van a szolgáltatási ablakokon kívül, az AlarmManager csak a setAndAllowWhileIdle() jelzőkkel működik, 9 percenként 1 alkalommal korlátozva. Az FCM high-priority értesítések továbbra is kézbesítve vannak, de nem emelhetik meg a bucket-et.

Korlátozások az App Standby-ban

App Standby korlátozásokat ír elő a háttérműveletek több kategóriájára. Ellentétben a Doze-zal, az App Standby korlátozásai a képernyő állapotától és a töltőtől függetlenül működnek. A fejlesztőnek ezeket a korlátozásokat figyelembe véve kell megterveznie az alkalmazást, különösen ha a célközönség rendszertelenül használja az alkalmazást.

JobScheduler és WorkManager

JobScheduler — a fő API, amelyre az App Standby hatással van. A bucket-től függően a feladatok végrehajtásának késleltetése 2 és 24 óra között változik. A WorkManager, amely a JobScheduler-et használja a motorháztető alatt (API 23+ rendszeren), szintén ki van téve ezeknek a késleltetéseknek. Időben kritikus feladatokhoz használja az Expedited Work funkciót, amely egy Foreground Service-t indít a motorháztető alatt, és nem függ a bucket-től.

Hálózati korlátozások

A Working Set, Frequent és Rare bucket-ben lévő alkalmazások nem végezhetnek tetszőleges hálózati kéréseket bármikor. A rendszer csak a Doze-zal szinkronizált szolgáltatási ablakokban engedélyezi a hálózathoz való hozzáférést. Kritikus adatok küldéséhez használja a FCM high-priority funkciót, majd a szolgáltatási ablakban történő szinkronizálást.

AlarmManager

AlarmManager az App Standby-ban ugyanazoknak a szabályoknak van alávetve, mint a Doze-ban: a pontos ébresztések (setExact()) késleltetve vannak, a setAndAllowWhileIdle() pedig 9 percenként 1 alkalomra korlátozott. A Rare bucket esetében a késleltetés elérheti a 24 órát, ami alkalmatlanná teszi az AlarmManager-t a feladatok pontos ütemezésére a ritkán használt alkalmazásokban.

• JobScheduler — a feladatok 2–24 órát késnek a bucket-től függően
• Hálózat — csak szolgáltatási ablakokban érhető el Working Set és az alatti szinteken
• AlarmManager — a pontos ébresztések késnek; setAndAllowWhileIdle — 1/9 perc
• SyncManager — a fiókok szinkronizálása a szolgáltatási ablakig késik
• Widget updates — a widget-ek frissítésének gyakorisága csökkenthető

Hogyan kaphat felmentést

Felmentés az App Standby alól kétféleképpen szerezhető: a felhasználói akkumulátor-beállításokon keresztül (kézi Whitelist) vagy a rendszer Intent-en keresztül: ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. A Google azonban szigorúan szabályozza a felmentésekhez való hozzáférést — azon alkalmazások, amelyeknek nincs nyomós okuk a felmentésre, kockáztatják a Google Play-ről való elutasítást.

A felhasználó manuálisan kikapcsolhatja a korlátozásokat egy adott alkalmazáshoz a Beállítások → Alkalmazások → [Alkalmazás] → Akkumulátor → Optimalizálás → Ne optimalizálja útvonalon. Ez teljesen eltávolítja az App Standby és Doze korlátozásait a kiválasztott alkalmazáshoz. A fejlesztő megjeleníthet egy útmutatót vagy rendszerpárbeszédpanelt a felhasználónak, de nem kényszerítheti az alkalmazás felvételeit a kivételek közé.

Foreground Service értesítéssel automatikusan ideiglenes felmentést kap az App Standby alól. Amíg a szolgáltatás fut és megjeleníti az értesítést, az alkalmazás átkerül az Active bucket-be, függetlenül a tényleges szintjétől. A szolgáltatás leállítása után a bucket visszatér az eredeti értékre. Ez a legmegbízhatóbb módja a háttérmunka garantálásának rendszerkivételek kérése nélkül.

Mikor kérjen felmentést

Whitelist kérése csak kritikus háttérfunkcionalitással rendelkező alkalmazásoknál van értelme: valós idejű navigáció, egészségügyi monitorozás, VoIP-hívások, eszközvédelom. A legtöbb alkalmazás esetében elegendő a Foreground Service vagy a WorkManager használata. A Google Play elutasíthatja a közzétételt, ha az alkalmazás nyilvánvaló szükség nélkül kér felmentést.

// Felmentés kérése az App Standby alól
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Aktuális állapot ellenőrzése
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

App Standby tesztelése

Tesztelés Az App Standby ADB-n keresztül történő tesztelése lehetővé teszi bármely bucket erőltetett hozzárendelését az alkalmazáshoz és viselkedésének ellenőrzését. Ez kritikus fontosságú azon alkalmazásoknál, amelyek háttér-szinkronizálásra, értesítésekre vagy időszakos frissítésekre támaszkodnak. A tesztelést fizikai eszközön vagy Android 9+ rendszerű emulátoron kell végezni.

A bucket erőltetett beállításához a adb shell am set-standby-bucket [package] [bucket] parancsot használjuk, ahol a bucket lehet: active, working_set, frequent vagy rare. Az aktuális bucket megtekintéséhez — adb shell am get-standby-bucket [package]. A rendszer lehetővé teszi az alkalmazás hosszú távú inaktivitásának szimulálását is a adb shell dumpsys usagestats paranccsal.

# Rare bucket beállítása az alkalmazáshoz
$ adb shell am set-standby-bucket com.example.app rare

# Aktuális bucket megtekintése
$ adb shell am get-standby-bucket com.example.app

# Összes bucket visszaállítása Active-ra
$ adb shell dumpsys usagestats clear

# Rendszer összes bucket-jének megtekintése
$ adb shell dumpsys usagestats

Mit ellenőrizzön

A Rare bucket beállítása után ellenőrizze: végrehajtódik-e a WorkManager-feladat 24 órán belül, aktiválódik-e az AlarmManager, kézbesítve vannak-e az FCM-értesítések, működik-e a Foreground Service korlátozások nélkül. A WorkManager Expedited Work szabályzattal azonnal végre kell hajtódjon még a Rare bucket-ben is, mivel Foreground Service-t használ. A szokásos WorkManager-feladatok a bucket-nek megfelelően késleltetve lesznek.

Legjobb gyakorlatok

Az App Standby-val szemben ellenálló alkalmazás fejlesztése tudatos hozzáállást igényel a háttérfeladatokhoz. Az alapelv: ne feltételezze, hogy az alkalmazás mindig Active bucket-ben van. Tervezze meg a háttérmunkát úgy, hogy az megfelelően működjön a Frequent és Rare bucket-ekre jellemző késleltetésekkel.

Használja a WorkManager-t az Expedited Work funkcióval

Expedited Work (WorkManager 2.7+) elindít egy Foreground Service-t a motorháztető alatt, ami azonnali végrehajtást biztosít a feladatnak a bucket-től függetlenül. Ez az optimális választás olyan feladatokhoz, amelyek nem késleltethetők: üzenet küldése, szinkronizálás fizetés után, bejövő hívás feldolgozása. A szokásos WorkManager-feladatok a szolgáltatási ablakokban hajtódnak végre, figyelembe véve a bucket-et.

FCM az újraaktiváláshoz

Használjon FCM high-priority üzeneteket az alkalmazás App Standby-ból való felébresztéséhez. Amikor az alkalmazás ilyen üzenetet kap, bucket-je ideiglenesen Active-ra emelkedik, és végrehajthatja a szükséges feladatokat (szinkronizálás, adatfrissítés). A feldolgozás befejezése után a bucket visszatér az eredeti szintre.

Kerülje az állandó memóriában tartást

Ne próbálja megkerülni az App Standby-t állandó háttérszolgáltatásokkal, WakeLock-kal vagy időszakos FCM-üzenetekkel. A Google aktívan küzd az ilyen gyakorlatok ellen — az alkalmazás energiaigényesként jelölhető meg és még szigorúbban korlátozható. Használja a WorkManager-t az időszakos feladatokhoz, a Foreground Service-t pedig csak akkor, ha a feladat ténylegesen látható a felhasználó számára.

• WorkManager — előnyben részesített API; az Expedited Work késleltetés nélkül hajtja végre a feladatokat
• FCM high-priority — ideiglenesen Active-ra emeli a bucket-et az üzenet feldolgozásához
• Ne kerülje meg az App Standby-t — ez az alkalmazás rendszer általi blokkolásához vezet
• Foreground Service — ideiglenesen Active-ba helyezi az alkalmazást a működés idejére
• Tesztelje az alkalmazást a Rare és Frequent bucket-ekben ADB-n keresztül minden kiadás előtt