App Standby — ce este, niveluri de așteptare și principiul de funcționare

Ce este App Standby

App Standby este o componentă a sistemului de gestionare a energiei Android, introdusă în Android 6.0 (API 23) și reproiectată semnificativ în Android 9 (API 28). Sarcina sa este de a determina ce aplicații sunt rar utilizate de utilizator și de a limita activitatea lor de fundal: solicitări de rețea, sincronizare, JobScheduler și AlarmManager. Spre deosebire de Doze, App Standby nu depinde de starea ecranului sau de mișcarea dispozitivului.

Sistemul clasifică aplicațiile în patru bucket-uri (niveluri): Active, Working Set, Frequent și Rare. Fiecare nivel determină cât de mult este limitată activitatea de fundal. Tranziția între niveluri are loc automat pe baza tiparelor de utilizare a aplicației: cât de des o deschide utilizatorul, primește notificări, interacționează cu widget-uri.

App Standby funcționează împreună cu Doze Mode, dar nu îl înlocuiește. Dacă Doze limitează activitatea de fundal a tuturor aplicațiilor când dispozitivul este inactiv, atunci App Standby limitează aplicații specifice independent de starea dispozitivului. O aplicație cu nivelul Rare va avea restricții chiar și în timpul utilizării active a telefonului, dacă utilizatorul nu a deschis-o de câteva zile.

Bucket în Android 9+

Începând cu Android 9 (API 28), Google a introdus App Standby Buckets — o clasificare formală cu valori numerice. Sistemul utilizează învățarea automată pentru a prezice următoarea lansare a aplicației. Dacă modelul prezice că aplicația va fi deschisă în orele următoare, primește bucket-ul Active. Dacă predicția indică o utilizare rară — este atribuit Rare.

Cum funcționează App Standby

App Standby analizează mai mulți factori pentru a determina bucket-ul: timpul de la ultima deschidere a aplicației de către utilizator, frecvența interacțiunii (numărul de lansări pe zi/săptămână), primirea notificărilor FCM, prezența widget-urilor active pe ecranul de pornire și abonarea la AlarmManager. Cu cât aplicația nu este utilizată mai mult, cu atât bucket-ul său este mai scăzut și restricțiile mai stricte.

Serviciul de sistem UsageStatsManager colectează statistici de utilizare a aplicațiilor și le transmite către StandbyController — o componentă a framework-ului care calculează bucket-ul pentru fiecare aplicație. StandbyController ia în considerare și evenimentele de sistem: după actualizarea aplicației, bucket-ul său este resetat la Active pentru câteva zile, astfel încât utilizatorul să poată evalua noile funcții.

O caracteristică importantă: App Standby nu ucide procesul aplicației, ci îi limitează capacitățile de fundal. Aplicația continuă să funcționeze dacă utilizatorul interacționează cu ea (bucket Active). De îndată ce utilizatorul minimizează aplicația și nu revine la ea, sistemul începe să numere timpul de inactivitate și poate reduce bucket-ul la Working Set sau Frequent.

Influența FCM asupra bucket-ului

Primirea unui mesaj FCM high-priority poate crește temporar bucket-ul aplicației la Active. Acest lucru oferă aplicației posibilitatea de a executa o sarcină (procesarea mesajului, sincronizarea datelor) fără restricții. Cu toate acestea, după finalizarea procesării, bucket-ul revine la valoarea inițială. Google recomandă utilizarea acestui mecanism pentru livrarea notificărilor importante, nu pentru menținerea aplicației „în viață”.

Nivelurile App Standby

App Standby utilizează patru niveluri (bucket-uri) pentru clasificarea aplicațiilor. Fiecare nivel determină timpul de întârziere pentru sarcinile de fundal: cu cât nivelul este mai scăzut, cu atât întârzierea este mai mare. Sistemul mută automat aplicația între niveluri pe baza statisticilor de utilizare colectate în ultimele 7–14 zile.

Active — aplicație activă

Active — aplicația cu care utilizatorul a interacționat recent (a lansat, a primit o notificare sau a folosit un widget). În acest bucket nu există restricții: JobScheduler se lansează imediat, rețeaua este disponibilă, AlarmManager funcționează exact. Aplicația rămâne în Active până când utilizatorul încetează să interacționeze cu ea timp de câteva ore.

Working Set și Frequent

Working Set — aplicația este utilizată regulat (de câteva ori pe săptămână). Întârzierea sarcinilor de fundal până la 2 ore. Frequent — aplicația este utilizată de câteva ori pe lună. Întârziere până la 4 ore. În ambele niveluri, rețeaua este disponibilă doar în ferestrele de serviciu, iar AlarmManager poate fi întârziat. JobScheduler execută sarcinile în cea mai apropiată fereastră.

Rare — rar utilizată

Rare — cel mai strict nivel, atribuit aplicațiilor pe care utilizatorul nu le-a deschis de peste 30 de zile. Întârzierea sarcinilor de fundal atinge 24 de ore. Rețeaua este complet blocată în afara ferestrelor de serviciu, AlarmManager funcționează doar cu flag-urile setAndAllowWhileIdle() cu limitarea de 1 dată la 9 minute. Notificările FCM high-priority sunt încă livrate, dar nu pot crește bucket-ul.

Restricții în App Standby

App Standby impune restricții asupra mai multor categorii de operațiuni de fundal. Spre deosebire de Doze, restricțiile App Standby acționează independent de starea ecranului și de încărcător. Dezvoltatorul trebuie să proiecteze aplicația ținând cont de aceste restricții, mai ales dacă publicul țintă utilizează aplicația neregulat.

JobScheduler și WorkManager

JobScheduler — API-ul principal asupra căruia App Standby are impact. În funcție de bucket, întârzierea executării sarcinilor variază între 2 și 24 de ore. WorkManager, care folosește JobScheduler sub capotă (pe API 23+), este de asemenea supus acestor întârzieri. Pentru sarcinile critice din punct de vedere temporal, utilizați Expedited Work, care lansează un Foreground Service sub capotă și nu depinde de bucket.

Restricții de rețea

Aplicațiile în bucket-ul Working Set, Frequent și Rare nu pot efectua solicitări de rețea arbitrare în orice moment. Sistemul permite accesul la rețea doar în ferestrele de serviciu sincronizate cu Doze. Pentru trimiterea datelor critice, utilizați FCM high-priority cu sincronizare ulterioară în fereastra de serviciu.

AlarmManager

AlarmManager în App Standby respectă aceleași reguli ca în Doze: alarmele exacte (setExact()) sunt întârziate, iar setAndAllowWhileIdle() este limitat la 1 declanșare la 9 minute. Pentru bucket-ul Rare, întârzierea poate atinge 24 de ore, ceea ce face AlarmManager nepotrivit pentru planificarea exactă a sarcinilor în aplicațiile rar utilizate.

• JobScheduler — sarcinile sunt întârziate 2–24 ore în funcție de bucket
• Rețea — acces doar în ferestrele de serviciu pentru Working Set și mai jos
• AlarmManager — alarmele exacte sunt întârziate; setAndAllowWhileIdle — 1/9 min
• SyncManager — sincronizarea conturilor este întârziată până la fereastra de serviciu
• Widget updates — frecvența actualizării widget-urilor poate fi redusă

Cum să obțineți excepție

Excepția din App Standby poate fi obținută în două moduri: prin setările bateriei utilizatorului (Whitelist manual) sau prin Intent-ul de sistem ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Cu toate acestea, Google reglementează strict accesul la excepții — aplicațiile care nu au un motiv întemeiat pentru excepție riscă să fie respinse pe Google Play.

Utilizatorul poate dezactiva manual restricțiile pentru o anumită aplicație prin Setări → Aplicații → [Aplicație] → Baterie → Optimizare → Nu optimiza. Acest lucru elimină complet restricțiile App Standby și Doze pentru aplicația selectată. Dezvoltatorul poate afișa utilizatorului o instrucțiune sau un dialog de sistem, dar nu poate forța adăugarea aplicației în excepții.

Foreground Service cu notificare primește automat o excepție temporară din App Standby. Cât timp serviciul funcționează și afișează notificarea, aplicația este transferată în bucket-ul Active, indiferent de nivelul său real. După oprirea serviciului, bucket-ul revine la valoarea inițială. Aceasta este cea mai sigură modalitate de a garanta munca de fundal fără a solicita excepții de sistem.

Când să solicitați excepția

Solicitarea Whitelist are sens doar pentru aplicațiile cu funcționalitate critică de fundal: navigare în timp real, monitorizare sănătate, apeluri VoIP, protecție dispozitiv. Pentru majoritatea aplicațiilor, este suficient să utilizați Foreground Service sau WorkManager. Google Play poate respinge publicarea dacă aplicația solicită excepția fără o necesitate evidentă.

// Solicitare excepție de la App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Verificare status curent
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Testarea App Standby

Testarea App Standby prin ADB permite atribuirea forțată a oricărui bucket aplicației și verificarea comportamentului său. Acest lucru este critic pentru aplicațiile care se bazează pe sincronizarea de fundal, notificări sau actualizări periodice. Testarea trebuie efectuată pe un dispozitiv fizic sau emulator cu Android 9+.

Pentru setarea forțată a bucket-ului se utilizează comanda adb shell am set-standby-bucket [package] [bucket], unde bucket poate fi: active, working_set, frequent sau rare. Pentru vizualizarea bucket-ului curent — adb shell am get-standby-bucket [package]. Sistemul permite, de asemenea, simularea inactivității prelungite a aplicației prin comanda adb shell dumpsys usagestats.

# Setare bucket Rare pentru aplicație
$ adb shell am set-standby-bucket com.example.app rare

# Vizualizare bucket curent
$ adb shell am get-standby-bucket com.example.app

# Resetare toate bucket-urile la Active
$ adb shell dumpsys usagestats clear

# Vizualizare toate bucket-urile sistemului
$ adb shell dumpsys usagestats

Ce să verificați

După setarea bucket-ului Rare verificați: dacă sarcina WorkManager se execută în 24 de ore, dacă AlarmManager se declanșează, dacă notificările FCM sunt livrate, dacă Foreground Service funcționează fără restricții. WorkManager cu politica Expedited Work ar trebui să se execute imediat chiar și în bucket-ul Rare, deoarece utilizează Foreground Service. Sarcinile obișnuite WorkManager vor fi întârziate în conformitate cu bucket-ul.

Cele mai bune practici

Dezvoltarea unei aplicații rezistente la App Standby necesită o abordare conștientă a sarcinilor de fundal. Principiul de bază: nu presupuneți că aplicația este întotdeauna în bucket-ul Active. Proiectați munca de fundal astfel încât să funcționeze corect cu întârzierile caracteristice bucket-urilor Frequent și Rare.

Utilizați WorkManager cu Expedited Work

Expedited Work (WorkManager 2.7+) lansează un Foreground Service sub capotă, oferind sarcinii o execuție imediată independent de bucket. Aceasta este alegerea optimă pentru sarcinile care nu pot fi întârziate: trimiterea unui mesaj, sincronizarea după plată, procesarea unui apel primit. Sarcinile obișnuite WorkManager se execută în ferestrele de serviciu ținând cont de bucket.

FCM pentru reactivare

Utilizați mesaje FCM high-priority pentru a trezi aplicația din App Standby. Când aplicația primește un astfel de mesaj, bucket-ul său crește temporar la Active și poate executa sarcinile necesare (sincronizare, actualizare date). După finalizarea procesării, bucket-ul revine la nivelul inițial.

Evitați menținerea constantă în memorie

Nu încercați să ocoliți App Standby cu servicii de fundal permanente, WakeLock sau mesaje FCM periodice. Google combate activ astfel de practici — aplicația poate fi marcată ca consumatoare de energie și limitată și mai strict. Utilizați WorkManager pentru sarcini periodice și Foreground Service doar când sarcina este cu adevărat vizibilă pentru utilizator.

• WorkManager — API-ul preferat; Expedited Work execută sarcinile fără întârziere
• FCM high-priority — crește temporar bucket-ul la Active pentru procesarea mesajului
• Nu ocoliți App Standby — acest lucru duce la blocarea aplicației de către sistem
• Foreground Service — transferă temporar aplicația în Active pe durata funcționării
• Testați aplicația în bucket-urile Rare și Frequent prin ADB înainte de fiecare lansare