App Standby — wat is het, wachtniveaus en werkingsprincipe

Wat is App Standby

App Standby is een component van het energiebeheersysteem van Android, geïntroduceerd in Android 6.0 (API 23) en aanzienlijk herzien in Android 9 (API 28). De taak is om te bepalen welke apps zelden door de gebruiker worden gebruikt en hun achtergrondactiviteit te beperken: netwerkverzoeken, synchronisatie, JobScheduler en AlarmManager. In tegenstelling tot Doze is App Standby niet afhankelijk van de schermstatus of beweging van het apparaat.

Het systeem classificeert apps in vier buckets (niveaus): Active, Working Set, Frequent en Rare. Elk niveau bepaalt hoe beperkt de achtergrondactiviteit is. De overgang tussen niveaus gebeurt automatisch op basis van gebruikspatronen van de app: hoe vaak de gebruiker deze opent, meldingen ontvangt, interactie heeft met widgets.

App Standby werkt samen met Doze Mode, maar vervangt het niet. Als Doze de achtergrondactiviteit van alle apps beperkt wanneer het apparaat inactief is, beperkt App Standby specifieke apps onafhankelijk van de apparaatstatus. Een app met het niveau Rare zal beperkingen hebben, zelfs tijdens actief telefoongebruik, als de gebruiker deze dagen niet heeft geopend.

Bucket in Android 9+

Vanaf Android 9 (API 28) heeft Google App Standby Buckets geïntroduceerd — een formele classificatie met numerieke waarden. Het systeem gebruikt machine learning om de volgende start van een app te voorspellen. Als het model voorspelt dat de app binnen de komende uren wordt geopend, krijgt deze de Active bucket. Als de voorspelling wijst op zeldzaam gebruik — wordt Rare toegewezen.

Hoe werkt App Standby

App Standby analyseert verschillende factoren om de bucket te bepalen: tijd sinds de laatste opening van de app door de gebruiker, interactiefrequentie (aantal keren starten per dag/week), ontvangen van FCM-meldingen, aanwezigheid van actieve widgets op het startscherm en abonnement op AlarmManager. Hoe langer een app niet wordt gebruikt, hoe lager de bucket en hoe strenger de beperkingen.

De systeemservice UsageStatsManager verzamelt gebruiksstatistieken van apps en geeft deze door aan StandbyController — een frameworkcomponent die de bucket voor elke app berekent. StandbyController houdt ook rekening met systeemgebeurtenissen: na een update van de app wordt de bucket voor een paar dagen gereset naar Active, zodat de gebruiker de nieuwe functies kan evalueren.

Een belangrijke eigenschap: App Standby beëindigt het proces van de app niet, maar beperkt de achtergrondmogelijkheden. De app blijft werken als de gebruiker ermee interacteert (bucket Active). Zodra de gebruiker de app minimaliseert en er niet naar terugkeert, begint het systeem de inactiviteitstijd te tellen en kan de bucket verlagen naar Working Set of Frequent.

Invloed van FCM op de bucket

Het ontvangen van een FCM high-priority bericht kan de bucket van de app tijdelijk verhogen naar Active. Dit geeft de app de mogelijkheid om een taak uit te voeren (bericht verwerken, gegevens synchroniseren) zonder beperkingen. Na voltooiing van de verwerking keert de bucket echter terug naar de oorspronkelijke waarde. Google raadt aan dit mechanisme te gebruiken voor het leveren van belangrijke meldingen, niet om de app “leven” te houden.

App Standby niveaus

App Standby gebruikt vier niveaus (buckets) voor de classificatie van apps. Elk niveau bepaalt de vertragingstijd voor achtergrondtaken: hoe lager het niveau, hoe langer de vertraging. Het systeem verplaatst de app automatisch tussen niveaus op basis van gebruiksstatistieken verzameld in de afgelopen 7–14 dagen.

Active — actieve app

Active — de app waarmee de gebruiker recent heeft geïnteracteerd (gestart, een melding ontvangen of een widget gebruikt). In deze bucket zijn er geen beperkingen: JobScheduler start onmiddellijk, netwerk is beschikbaar, AlarmManager werkt precies. De app blijft in Active totdat de gebruiker gedurende enkele uren stopt met interactie.

Working Set en Frequent

Working Set — de app wordt regelmatig gebruikt (meerdere keren per week). Vertraging van achtergrondtaken tot 2 uur. Frequent — de app wordt meerdere keren per maand gebruikt. Vertraging tot 4 uur. Op beide niveaus is netwerk alleen beschikbaar in onderhoudsvensters en kan AlarmManager worden uitgesteld. JobScheduler voert taken uit in het dichtstbijzijnde venster.

Rare — zelden gebruikt

Rare — het strengste niveau, toegewezen aan apps die de gebruiker meer dan 30 dagen niet heeft geopend. Vertraging van achtergrondtaken bereikt 24 uur. Netwerk is volledig geblokkeerd buiten onderhoudsvensters, AlarmManager werkt alleen met vlaggen setAndAllowWhileIdle() met een beperking van 1 keer per 9 minuten. FCM high-priority meldingen worden nog steeds bezorgd, maar kunnen de bucket niet verhogen.

Beperkingen in App Standby

App Standby legt beperkingen op aan verschillende categorieën achtergrondbewerkingen. In tegenstelling tot Doze werken de beperkingen van App Standby onafhankelijk van de schermstatus en oplader. De ontwikkelaar moet de app ontwerpen rekening houdend met deze beperkingen, vooral als de doelgroep de app onregelmatig gebruikt.

JobScheduler en WorkManager

JobScheduler — de belangrijkste API waarop App Standby invloed heeft. Afhankelijk van de bucket varieert de vertraging van taakuitvoering van 2 tot 24 uur. WorkManager, dat onder de motorkap JobScheduler gebruikt (op API 23+), is ook onderhevig aan deze vertragingen. Gebruik voor tijdkritische taken Expedited Work, dat een Foreground Service onder de motorkap start en niet afhankelijk is van de bucket.

Netwerkbeperkingen

Apps in de bucket Working Set, Frequent en Rare kunnen op elk moment geen willekeurige netwerkverzoeken uitvoeren. Het systeem staat alleen toegang tot het netwerk toe in onderhoudsvensters die zijn gesynchroniseerd met Doze. Gebruik voor het verzenden van kritieke gegevens FCM high-priority met daaropvolgende synchronisatie in het onderhoudsvenster.

AlarmManager

AlarmManager in App Standby is onderworpen aan dezelfde regels als in Doze: exacte alarmen (setExact()) worden uitgesteld en setAndAllowWhileIdle() is beperkt tot 1 keer per 9 minuten. Voor de bucket Rare kan de vertraging 24 uur bereiken, wat AlarmManager ongeschikt maakt voor nauwkeurige planning van taken in zelden gebruikte apps.

• JobScheduler — taken worden 2–24 uur uitgesteld afhankelijk van de bucket
• Netwerk — alleen toegang in onderhoudsvensters voor Working Set en lager
• AlarmManager — exacte alarmen worden uitgesteld; setAndAllowWhileIdle — 1/9 min
• SyncManager — accountsynchronisatie wordt uitgesteld tot onderhoudsvenster
• Widget updates — frequentie van widget-updates kan worden verlaagd

Hoe uitzondering krijgen

Uitzondering van App Standby kan op twee manieren worden verkregen: via de batterij-instellingen van de gebruiker (handmatige Whitelist) of via de systeem-Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Google reguleert echter streng de toegang tot uitzonderingen — apps zonder geldige reden voor uitzondering riskeren afwijzing op Google Play.

De gebruiker kan handmatig beperkingen uitschakelen voor een specifieke app via Instellingen → Apps → [App] → Batterij → Optimalisatie → Niet optimaliseren. Dit verwijdert volledig de beperkingen van App Standby en Doze voor de geselecteerde app. De ontwikkelaar kan de gebruiker een instructie of systeemdialoog tonen, maar kan de app niet geforceerd toevoegen aan uitzonderingen.

Foreground Service met melding krijgt automatisch een tijdelijke uitzondering van App Standby. Zolang de service draait en de melding weergeeft, wordt de app overgezet naar bucket Active, ongeacht het werkelijke niveau. Na het stoppen van de service keert de bucket terug naar de oorspronkelijke waarde. Dit is de meest betrouwbare manier om achtergrondwerk te garanderen zonder systeemuitzonderingen aan te vragen.

Wanneer uitzondering aanvragen

Het aanvragen van Whitelist heeft alleen zin voor apps met kritieke achtergrondfunctionaliteit: real-time navigatie, gezondheidsmonitoring, VoIP-oproepen, apparaatbeveiliging. Voor de meeste apps is het voldoende om Foreground Service of WorkManager te gebruiken. Google Play kan publicatie weigeren als de app zonder duidelijke noodzaak een uitzondering aanvraagt.

// Verzoek om uitzondering van App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

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

App Standby testen

Testen van App Standby via ADB maakt het mogelijk om een app gedwongen een bucket toe te wijzen en het gedrag te controleren. Dit is cruciaal voor apps die afhankelijk zijn van achtergrondsynchronisatie, meldingen of periodieke updates. Testen moet worden uitgevoerd op een fysiek apparaat of emulator met Android 9+.

Voor het gedwongen instellen van de bucket wordt de opdracht adb shell am set-standby-bucket [package] [bucket] gebruikt, waarbij bucket kan zijn: active, working_set, frequent of rare. Voor het bekijken van de huidige bucket — adb shell am get-standby-bucket [package]. Het systeem maakt ook simulatie mogelijk van langdurige inactiviteit van de app via de opdracht adb shell dumpsys usagestats.

# Bucket Rare instellen voor app
$ adb shell am set-standby-bucket com.example.app rare

# Huidige bucket bekijken
$ adb shell am get-standby-bucket com.example.app

# Alle buckets resetten naar Active
$ adb shell dumpsys usagestats clear

# Alle systeembuckets bekijken
$ adb shell dumpsys usagestats

Wat te controleren

Na het instellen van de bucket Rare controleer: of de WorkManager-taak binnen 24 uur wordt uitgevoerd, of AlarmManager wordt geactiveerd, of FCM-meldingen worden bezorgd, of Foreground Service zonder beperkingen werkt. WorkManager met Expedited Work-beleid moet onmiddellijk worden uitgevoerd, zelfs in bucket Rare, omdat het Foreground Service gebruikt. Gewone WorkManager-taken worden uitgesteld volgens de bucket.

Beste praktijken

Het ontwikkelen van een app die bestand is tegen App Standby vereist een bewuste benadering van achtergrondtaken. Het basisprincipe: neem niet aan dat de app altijd in bucket Active is. Ontwerp achtergrondwerk zodanig dat het correct werkt met vertragingen die kenmerkend zijn voor de buckets Frequent en Rare.

Gebruik WorkManager met Expedited Work

Expedited Work (WorkManager 2.7+) start een Foreground Service onder de motorkap, waardoor de taak onmiddellijk wordt uitgevoerd, onafhankelijk van de bucket. Dit is de optimale keuze voor taken die niet kunnen worden uitgesteld: verzenden van een bericht, synchronisatie na betaling, verwerking van een inkomende oproep. Gewone WorkManager-taken worden uitgevoerd in onderhoudsvensters, rekening houdend met de bucket.

FCM voor reactivatie

Gebruik FCM high-priority berichten om de app uit App Standby te wekken. Wanneer de app een dergelijk bericht ontvangt, wordt de bucket tijdelijk verhoogd naar Active en kan het noodzakelijke taken uitvoeren (synchronisatie, gegevensupdate). Na voltooiing van de verwerking keert de bucket terug naar het oorspronkelijke niveau.

Vermijd constant in geheugen houden

Probeer App Standby niet te omzeilen met permanente achtergrondservices, WakeLock of periodieke FCM-berichten. Google bestrijdt actief dergelijke praktijken — de app kan worden gemarkeerd als energieverslindend en nog strenger worden beperkt. Gebruik WorkManager voor periodieke taken en Foreground Service alleen wanneer de taak daadwerkelijk zichtbaar is voor de gebruiker.

• WorkManager — voorkeurs-API; Expedited Work voert taken uit zonder vertraging
• FCM high-priority — verhoogt tijdelijk de bucket naar Active voor berichtverwerking
• Omzeil niet App Standby — dit leidt tot blokkering van de app door het systeem
• Foreground Service — zet de app tijdelijk over naar Active tijdens de werking
• Test de app in buckets Rare en Frequent via ADB voor elke release