App Standby — was ist das, Wartestufen und Funktionsprinzip

Was ist App Standby

App Standby ist eine Komponente des Android-Energieverwaltungssystems, eingeführt in Android 6.0 (API 23) und erheblich überarbeitet in Android 9 (API 28). Seine Aufgabe ist es, Apps zu identifizieren, die der Benutzer selten nutzt, und deren Hintergrundaktivität einzuschränken: Netzwerkanfragen, Synchronisierung, JobScheduler und AlarmManager. Anders als Doze hängt App Standby nicht vom Bildschirmstatus oder der Gerätebewegung ab.

Das System klassifiziert Apps in vier Buckets (Stufen): Active, Working Set, Frequent und Rare. Jede Stufe bestimmt, wie stark die Hintergrundaktivität eingeschränkt wird. Die Übergänge zwischen den Stufen erfolgen automatisch basierend auf den Nutzungsmustern der App: wie oft der Benutzer sie öffnet, Benachrichtigungen erhält, mit Widgets interagiert.

App Standby arbeitet mit Doze Mode zusammen, ersetzt ihn aber nicht. Während Doze die Hintergrundaktivität aller Apps bei Geräte-Leerlauf einschränkt, schränkt App Standby bestimmte Apps unabhängig vom Gerätestatus ein. Eine App auf der Rare-Stufe unterliegt Einschränkungen, selbst wenn das Telefon aktiv genutzt wird, wenn der Benutzer sie mehrere Tage lang nicht geöffnet hat.

Buckets in Android 9+

Ab Android 9 (API 28) führte Google App Standby Buckets ein — eine formale Klassifizierung mit numerischen Werten. Das System verwendet maschinelles Lernen, um den nächsten Start einer App vorherzusagen. Wenn das Modell vorhersagt, dass die App in den nächsten Stunden geöffnet wird, erhält sie einen Active-Bucket. Wenn die Vorhersage auf seltene Nutzung hinweist — wird Rare zugewiesen.

Wie App Standby funktioniert

App Standby analysiert mehrere Faktoren zur Bestimmung des Buckets: Zeit seit dem letzten Öffnen der App durch den Benutzer, Interaktionshäufigkeit (Anzahl der Starts pro Tag/Woche), Erhalt von FCM-Benachrichtigungen, Vorhandensein aktiver Widgets auf dem Startbildschirm und Abonnement von AlarmManager. Je länger eine App ungenutzt bleibt, desto niedriger ist ihr Bucket und desto strenger die Einschränkungen.

Der Systemdienst UsageStatsManager sammelt Nutzungsstatistiken von Apps und übergibt sie an StandbyController — eine Framework-Komponente, die den Bucket für jede App berechnet. StandbyController berücksichtigt auch Systemereignisse: Nach einem App-Update wird der Bucket für einige Tage auf Active zurückgesetzt, damit der Benutzer die neuen Funktionen bewerten kann.

Eine wichtige Eigenschaft: App Standby beendet den App-Prozess nicht, sondern schränkt seine Hintergrundmöglichkeiten ein. Die App arbeitet weiter, wenn der Benutzer mit ihr interagiert (Active-Bucket). Sobald der Benutzer die App minimiert und nicht zu ihr zurückkehrt, beginnt das System mit der Zählung der Leerlaufzeit und kann den Bucket auf Working Set oder Frequent senken.

Auswirkung von FCM auf den Bucket

Der Empfang einer FCM-High-Priority-Nachricht kann den Bucket der App vorübergehend auf Active erhöhen. Dies gibt der App die Möglichkeit, eine Aufgabe (Nachrichtenverarbeitung, Datensynchronisierung) ohne Einschränkungen auszuführen. Nach Abschluss der Verarbeitung kehrt der Bucket jedoch zu seinem ursprünglichen Wert zurück. Google empfiehlt, diesen Mechanismus für die Zustellung wichtiger Benachrichtigungen zu verwenden, nicht um die App am Leben zu halten.

App Standby Stufen

App Standby verwendet vier Stufen (Buckets) zur Klassifizierung von Apps. Jede Stufe bestimmt die Verzögerungszeit für Hintergrundaufgaben: Je niedriger die Stufe, desto länger die Verzögerung. Das System verschiebt die App automatisch zwischen den Stufen basierend auf Nutzungsstatistiken der letzten 7–14 Tage.

Active — Aktive App

Active — eine App, mit der der Benutzer kürzlich interagiert hat (gestartet, Benachrichtigung erhalten oder Widget verwendet). In diesem Bucket gibt es keine Einschränkungen: JobScheduler wird sofort ausgeführt, Netzwerk ist verfügbar, AlarmManager löst präzise aus. Die App bleibt in Active, bis der Benutzer für mehrere Stunden aufhört, mit ihr zu interagieren.

Working Set und Frequent

Working Set — die App wird regelmäßig genutzt (mehrmals pro Woche). Hintergrundaufgabenverzögerung bis zu 2 Stunden. Frequent — die App wird mehrmals im Monat genutzt. Verzögerung bis zu 4 Stunden. In beiden Stufen ist das Netzwerk nur in Wartungsfenstern verfügbar, und AlarmManager kann verzögert werden. JobScheduler führt Aufgaben im nächsten Fenster aus.

Rare — Selten genutzt

Rare — die strengste Stufe, zugewiesen an Apps, die der Benutzer seit mehr als 30 Tagen nicht geöffnet hat. Die Verzögerung von Hintergrundaufgaben erreicht 24 Stunden. Das Netzwerk ist außerhalb von Wartungsfenstern vollständig blockiert, AlarmManager löst nur mit setAndAllowWhileIdle()-Flags mit einem Limit von 1 Mal alle 9 Minuten aus. FCM-High-Priority-Benachrichtigungen werden weiterhin zugestellt, können den Bucket aber nicht erhöhen.

Einschränkungen in App Standby

App Standby erlegt mehreren Kategorien von Hintergrundoperationen Einschränkungen auf. Anders als Doze gelten die App Standby-Einschränkungen unabhängig vom Bildschirmstatus und Ladezustand. Der Entwickler sollte die App unter Berücksichtigung dieser Einschränkungen entwerfen, insbesondere wenn die Zielgruppe die App unregelmäßig nutzt.

JobScheduler und WorkManager

JobScheduler — die wichtigste API, die von App Standby betroffen ist. Abhängig vom Bucket beträgt die Verzögerung der Aufgabenausführung 2 bis 24 Stunden. WorkManager, der unter der Haube JobScheduler verwendet (ab API 23), unterliegt ebenfalls diesen Verzögerungen. Für zeitkritische Aufgaben verwenden Sie Expedited Work, das einen Foreground Service unter der Haube startet und nicht vom Bucket beeinflusst wird.

Netzwerkbeschränkungen

Apps in den Buckets Working Set, Frequent und Rare können nicht jederzeit beliebige Netzwerkanfragen durchführen. Das System erlaubt Netzwerkzugriff nur in Wartungsfenstern, die mit Doze synchronisiert sind. Zum Senden kritischer Daten verwenden Sie FCM High-Priority mit anschließender Synchronisierung im Wartungsfenster.

AlarmManager

AlarmManager folgt in App Standby denselben Regeln wie in Doze: exakte Wecker (setExact()) werden verzögert, und setAndAllowWhileIdle() ist auf 1 Auslösung alle 9 Minuten beschränkt. Für den Rare-Bucket kann die Verzögerung 24 Stunden erreichen, was AlarmManager für die präzise Aufgabenplanung in selten genutzten Apps ungeeignet macht.

• JobScheduler — Aufgaben werden je nach Bucket um 2–24 Stunden verzögert
• Netzwerk — Zugriff nur in Wartungsfenstern für Working Set und darunter
• AlarmManager — exakte Wecker werden verzögert; setAndAllowWhileIdle — 1/9 min
• SyncManager — Kontosynchronisierung wird bis zum Wartungsfenster verzögert
• Widget-Updates — die Aktualisierungshäufigkeit von Widgets kann reduziert werden

Wie man eine Ausnahme erhält

Eine Ausnahme von App Standby kann auf zwei Wegen erreicht werden: über die Akku-Einstellungen des Benutzers (manuelle Whitelist) oder über den System-Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Google reguliert jedoch streng den Zugang zu Ausnahmen — Apps ohne triftigen Grund riskieren eine Ablehnung bei Google Play.

Der Benutzer kann Einschränkungen für eine bestimmte App manuell deaktivieren über Einstellungen → Apps → [App] → Akku → Optimierung → Nicht optimieren. Dies entfernt vollständig die App Standby- und Doze-Einschränkungen für die ausgewählte App. Der Entwickler kann dem Benutzer Anweisungen oder einen Systemdialog anzeigen, kann aber eine App nicht zwangsweise zu den Ausnahmen hinzufügen.

Foreground Service mit einer Benachrichtigung erhält automatisch eine temporäre Ausnahme von App Standby. Während der Dienst läuft und eine Benachrichtigung anzeigt, wird die App unabhängig von ihrer tatsächlichen Stufe in den Active-Bucket verschoben. Nachdem der Dienst stoppt, kehrt der Bucket zu seinem ursprünglichen Wert zurück. Dies ist der zuverlässigste Weg, um Hintergrundarbeit ohne Anforderung von Systemausnahmen zu gewährleisten.

Wann eine Ausnahme beantragen

Die Beantragung einer Whitelist ist nur für Apps mit kritischer Hintergrundfunktionalität sinnvoll: Echtzeit-Navigation, Gesundheitsüberwachung, VoIP-Anrufe, Geräteschutz. Für die meisten Apps reicht die Verwendung von Foreground Service oder WorkManager aus. Google Play kann die Veröffentlichung ablehnen, wenn die App ohne offensichtliche Notwendigkeit eine Ausnahme beantragt.

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

// Aktuellen Status prüfen
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

App Standby testen

Das Testen von App Standby über ADB ermöglicht es, einer App zwangsweise einen beliebigen Bucket zuzuweisen und ihr Verhalten zu überprüfen. Dies ist kritisch wichtig für Apps, die auf Hintergrundsynchronisierung, Benachrichtigungen oder regelmäßige Aktualisierungen angewiesen sind. Tests sollten auf einem physischen Gerät oder Emulator mit Android 9+ durchgeführt werden.

Um einen Bucket zwangsweise festzulegen, verwenden Sie den Befehl adb shell am set-standby-bucket [package] [bucket], wobei bucket sein kann: active, working_set, frequent oder rare. Zum Anzeigen des aktuellen Buckets — adb shell am get-standby-bucket [package]. Das System ermöglicht auch die Simulation längerer App-Inaktivität über den Befehl adb shell dumpsys usagestats.

# Rare Bucket für die App festlegen
$ adb shell am set-standby-bucket com.example.app rare

# Aktuellen Bucket anzeigen
$ adb shell am get-standby-bucket com.example.app

# Alle Buckets auf Active zurücksetzen
$ adb shell dumpsys usagestats clear

# Alle System-Buckets anzeigen
$ adb shell dumpsys usagestats

Was zu überprüfen ist

Nach dem Setzen des Buckets auf Rare überprüfen Sie: ob die WorkManager-Aufgabe innerhalb von 24 Stunden ausgeführt wird, ob AlarmManager auslöst, ob FCM-Benachrichtigungen zugestellt werden und ob Foreground Service ohne Einschränkungen funktioniert. WorkManager mit Expedited Work-Richtlinie sollte sofort ausgeführt werden, selbst im Rare-Bucket, da es Foreground Service verwendet. Reguläre WorkManager-Aufgaben werden entsprechend dem Bucket verzögert.

Bewährte Praktiken

Die Entwicklung einer gegen App Standby widerstandsfähigen App erfordert einen bewussten Ansatz bei Hintergrundaufgaben. Das Hauptprinzip: Gehen Sie nicht davon aus, dass die App immer im Active-Bucket ist. Gestalten Sie die Hintergrundarbeit so, dass sie korrekt mit den für Frequent- und Rare-Buckets charakteristischen Verzögerungen ausgeführt wird.

WorkManager mit Expedited Work verwenden

Expedited Work (WorkManager 2.7+) startet einen Foreground Service unter der Haube, was der Aufgabe eine sofortige Ausführung unabhängig vom Bucket ermöglicht. Dies ist die optimale Wahl für Aufgaben, die nicht verschoben werden können: Nachricht senden, Synchronisierung nach Zahlung, eingehender Anruf verarbeiten. Reguläre WorkManager-Aufgaben laufen in Wartungsfenstern entsprechend dem Bucket.

FCM zur Reaktivierung

Verwenden Sie FCM-High-Priority-Nachrichten, um eine App aus App Standby aufzuwecken. Wenn die App eine solche Nachricht erhält, wird ihr Bucket vorübergehend auf Active erhöht, sodass sie notwendige Aufgaben (Synchronisierung, Datenaktualisierung) ausführen kann. Nach Abschluss der Verarbeitung kehrt der Bucket zu seiner ursprünglichen Stufe zurück.

Vermeiden Sie ständigen Speicherverbleib

Versuchen Sie nicht, App Standby mit dauerhaften Hintergrunddiensten, WakeLock oder regelmäßigen FCM-Nachrichten zu umgehen. Google bekämpft solche Praktiken aktiv — die App kann als energieintensiv eingestuft und noch strenger eingeschränkt werden. Verwenden Sie WorkManager für regelmäßige Aufgaben und Foreground Service nur, wenn die Aufgabe für den Benutzer tatsächlich sichtbar ist.

• WorkManager — bevorzugte API; Expedited Work führt Aufgaben ohne Verzögerung aus
• FCM High-Priority — erhöht Bucket vorübergehend auf Active zur Nachrichtenverarbeitung
• Umgehen Sie nicht App Standby — dies führt zur Blockierung der App durch das System
• Foreground Service — verschiebt die App während der Ausführung vorübergehend in Active
• Testen Sie die App in Rare- und Frequent-Buckets über ADB vor jedem Release