App Standby — vad är det, väntelägesnivåer och funktionsprincip

Vad är App Standby

App Standby är en komponent i Android energihanteringssystem, introducerad i Android 6.0 (API 23) och betydligt omarbetad i Android 9 (API 28). Dess uppgift är att avgöra vilka appar som används sällan av användaren och begränsa deras bakgrundsaktivitet: nätverksförfrågningar, synkronisering, JobScheduler och AlarmManager. Till skillnad från Doze är App Standby inte beroende av skärmstatus eller enhetens rörelse.

Systemet klassificerar appar i fyra buckets (nivåer): Active, Working Set, Frequent och Rare. Varje nivå bestämmer hur mycket bakgrundsaktiviteten begränsas. Övergången mellan nivåer sker automatiskt baserat på appens användningsmönster: hur ofta användaren öppnar den, får notiser, interagerar med widgets.

App Standby fungerar tillsammans med Doze Mode, men ersätter det inte. Om Doze begränsar bakgrundsaktiviteten för alla appar när enheten är inaktiv, begränsar App Standby specifika appar oberoende av enhetens tillstånd. En app med nivån Rare kommer att ha begränsningar även vid aktiv telefonanvändning, om användaren inte har öppnat den på flera dagar.

Bucket i Android 9+

Från och med Android 9 (API 28) introducerade Google App Standby Buckets — en formell klassificering med numeriska värden. Systemet använder maskininlärning för att förutsäga nästa start av en app. Om modellen förutsäger att appen kommer att öppnas inom de närmaste timarna får den bucket Active. Om förutsägelsen indikerar sällan användning — tilldelas Rare.

Hur App Standby fungerar

App Standby analyserar flera faktorer för att bestämma bucket: tid sedan senaste öppning av appen av användaren, interaktionsfrekvens (antal startar per dag/vecka), mottagning av FCM-notiser, förekomst av aktiva widgets på startskärmen och prenumeration på AlarmManager. Ju längre en app inte används, desto lägre är dess bucket och desto strängare är begränsningarna.

Systemtjänsten UsageStatsManager samlar in användningsstatistik för appar och överför den till StandbyController — en framework-komponent som beräknar bucket för varje app. StandbyController tar också hänsyn till systemhändelser: efter en uppdatering av appen återställs dess bucket till Active i några dagar så att användaren kan utvärdera nya funktioner.

En viktig egenskap: App Standby dödar inte appens process, utan begränsar dess bakgrundsfunktioner. Appen fortsätter att fungera om användaren interagerar med den (bucket Active). Så snart användaren minimerar appen och inte återvänder till den, börjar systemet räkna inaktivitetstiden och kan sänka bucket till Working Set eller Frequent.

FCM:s påverkan på bucket

Mottagning av ett FCM high-priority-meddelande kan tillfälligt höja appens bucket till Active. Detta ger appen möjlighet att utföra en uppgift (bearbeta meddelandet, synkronisera data) utan begränsningar. Efter bearbetningens slutförande återgår dock bucket till det ursprungliga värdet. Google rekommenderar att använda denna mekanism för leverans av viktiga notiser, inte för att hålla appen “vid liv”.

App Standby nivåer

App Standby använder fyra nivåer (buckets) för klassificering av appar. Varje nivå bestämmer fördröjningstiden för bakgrundsuppgifter: ju lägre nivå, desto längre fördröjning. Systemet flyttar automatiskt appen mellan nivåer baserat på användningsstatistik som samlats in under de senaste 7–14 dagarna.

Active — aktiv app

Active — appen som användaren nyligen interagerat med (startat, fått en notis eller använt en widget). I denna bucket finns inga begränsningar: JobScheduler startar omedelbart, nätverket är tillgängligt, AlarmManager fungerar exakt. Appen förblir i Active tills användaren slutar interagera med den under flera timmar.

Working Set och Frequent

Working Set — appen används regelbundet (flera gånger i veckan). Fördröjning av bakgrundsuppgifter upp till 2 timmar. Frequent — appen används flera gånger i månaden. Fördröjning upp till 4 timmar. På båda nivåerna är nätverket endast tillgängligt i underhållsfönster och AlarmManager kan försenas. JobScheduler utför uppgifter i närmaste fönster.

Rare — sällan använd

Rare — den strängaste nivån, tilldelad appar som användaren inte har öppnat på mer än 30 dagar. Fördröjning av bakgrundsuppgifter når 24 timmar. Nätverket är helt blockerat utanför underhållsfönster, AlarmManager fungerar endast med flaggor setAndAllowWhileIdle() med begränsningen 1 gång per 9 minuter. FCM high-priority-notiser levereras fortfarande men kan inte höja bucket.

Begränsningar i App Standby

App Standby lägger begränsningar på flera kategorier av bakgrundsoperationer. Till skillnad från Doze fungerar App Standby-begränsningarna oberoende av skärmstatus och laddare. Utvecklaren bör designa appen med hänsyn till dessa begränsningar, särskilt om målgruppen använder appen oregelbundet.

JobScheduler och WorkManager

JobScheduler — det huvudsakliga API som påverkas av App Standby. Beroende på bucket varierar fördröjningen av uppgiftsutförande från 2 till 24 timmar. WorkManager, som använder JobScheduler under huven (på API 23+), är också föremål för dessa fördröjningar. För tidskritiska uppgifter, använd Expedited Work, som startar en Foreground Service under huven och inte är beroende av bucket.

Nätverksbegränsningar

Appar i bucket Working Set, Frequent och Rare kan inte utföra godtyckliga nätverksförfrågningar när som helst. Systemet tillåter åtkomst till nätverket endast i underhållsfönster som synkroniserats med Doze. För att skicka kritisk data, använd FCM high-priority med efterföljande synkronisering i underhållsfönstret.

AlarmManager

AlarmManager i App Standby lyder under samma regler som i Doze: exakta alarm (setExact()) försenas och setAndAllowWhileIdle() begränsas till 1 gång per 9 minuter. För bucket Rare kan fördröjningen nå 24 timmar, vilket gör AlarmManager olämplig för exakt planering av uppgifter i sällan använda appar.

• JobScheduler — uppgifter försenas 2–24 timmar beroende på bucket
• Nätverk — endast åtkomst i underhållsfönster för Working Set och lägre
• AlarmManager — exakta alarm försenas; setAndAllowWhileIdle — 1/9 min
• SyncManager — kontosynkronisering försenas till underhållsfönster
• Widget updates — frekvensen för widgetuppdateringar kan minskas

Hur man får undantag

Undantag från App Standby kan erhållas på två sätt: via användarens batteriinställningar (manuell Whitelist) eller via systemets Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Google reglerar dock strikt tillgången till undantag — appar som inte har en giltig anledning till undantag riskerar att avvisas på Google Play.

Användaren kan manuellt inaktivera begränsningar för en specifik app via Inställningar → Appar → [App] → Batteri → Optimering → Optimera inte. Detta tar helt bort App Standby- och Doze-begränsningarna för den valda appen. Utvecklaren kan visa en instruktion eller systemdialog för användaren, men kan inte tvångslägga till appen till undantag.

Foreground Service med notis får automatiskt ett tillfälligt undantag från App Standby. Så länge tjänsten körs och visar notisen överförs appen till bucket Active oavsett dess verkliga nivå. Efter att tjänsten stoppats återgår bucket till det ursprungliga värdet. Detta är det mest pålitliga sättet att garantera bakgrundsarbete utan att begära systemundantag.

När man ska begära undantag

Att begära Whitelist är endast meningsfullt för appar med kritisk bakgrundsfunktionalitet: realtidsnavigering, hälsoövervakning, VoIP-samtal, enhetsskydd. För de flesta appar räcker det att använda Foreground Service eller WorkManager. Google Play kan avvisa publicering om appen begär undantag utan uppenbart behov.

// Begäran om undantag från App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Kontroll av aktuell status
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Testa App Standby

Testning av App Standby via ADB gör det möjligt att tvångstilldela vilken bucket som helst till en app och kontrollera dess beteende. Detta är avgörande för appar som förlitar sig på bakgrundssynkronisering, notiser eller periodiska uppdateringar. Testning bör utföras på en fysisk enhet eller emulator med Android 9+.

För tvångsinställning av bucket används kommandot adb shell am set-standby-bucket [package] [bucket], där bucket kan vara: active, working_set, frequent eller rare. För att visa aktuell bucket — adb shell am get-standby-bucket [package]. Systemet tillåter också simulering av långvarig inaktivitet för appen via kommandot adb shell dumpsys usagestats.

# Ställa in bucket Rare för appen
$ adb shell am set-standby-bucket com.example.app rare

# Visa aktuell bucket
$ adb shell am get-standby-bucket com.example.app

# Återställa alla buckets till Active
$ adb shell dumpsys usagestats clear

# Visa alla systemets buckets
$ adb shell dumpsys usagestats

Vad att kontrollera

Efter inställning av bucket Rare kontrollera: om WorkManager-uppgiften utförs inom 24 timmar, om AlarmManager aktiveras, om FCM-notiser levereras, om Foreground Service fungerar utan begränsningar. WorkManager med Expedited Work-policy bör utföras omedelbart även i bucket Rare eftersom det använder Foreground Service. Vanliga WorkManager-uppgifter kommer att försenas enligt bucket.

Bästa praxis

Att utveckla en app som är motståndskraftig mot App Standby kräver ett medvetet förhållningssätt till bakgrundsuppgifter. Grundprincipen: anta inte att appen alltid är i bucket Active. Designa bakgrundsarbete så att det fungerar korrekt med fördröjningar som är karakteristiska för bucket Frequent och Rare.

Använd WorkManager med Expedited Work

Expedited Work (WorkManager 2.7+) startar en Foreground Service under huven, vilket ger uppgiften omedelbar exekvering oberoende av bucket. Detta är det optimala valet för uppgifter som inte kan försenas: skicka ett meddelande, synkronisera efter betalning, bearbeta ett inkommande samtal. Vanliga WorkManager-uppgifter utförs i underhållsfönster med hänsyn till bucket.

FCM för reaktivering

Använd FCM high-priority-meddelanden för att väcka appen från App Standby. När appen får ett sådant meddelande höjs dess bucket tillfälligt till Active och den kan utföra nödvändiga uppgifter (synkronisering, datauppdatering). Efter bearbetningens slutförande återgår bucket till den ursprungliga nivån.

Undvik konstant minneshållning

Försök inte kringgå App Standby med permanenta bakgrundstjänster, WakeLock eller periodiska FCM-meddelanden. Google bekämpar aktivt sådana metoder — appen kan markeras som energikrävande och begränsas ännu strängare. Använd WorkManager för periodiska uppgifter och Foreground Service endast när uppgiften verkligen är synlig för användaren.

• WorkManager — föredraget API; Expedited Work utför uppgifter utan fördröjning
• FCM high-priority — höjer tillfälligt bucket till Active för meddelandebearbetning
• Kringgå inte App Standby — detta leder till blockering av appen av systemet
• Foreground Service — överför tillfälligt appen till Active under drift
• Testa appen i bucket Rare och Frequent via ADB före varje release