App-Standby-Buckets

Android 9 (API-Level 28) und höher unterstützen App-Standby-Buckets. Mit App-Standby-Buckets kann das System die Ressourcenanfragen von Apps priorisieren, je nachdem, wie aktuell und wie häufig die Apps verwendet werden. Basierend auf den Nutzungsmustern der App wird jede App in einen der fünf Prioritäts-Buckets eingeordnet. Das System schränkt die für jede App verfügbaren Geräteressourcen je nach Bucket ein, in dem sich die App befindet.

Prioritäts-Buckets

Das System weist jeder App dynamisch einen Prioritäts-Bucket zu und weist die Apps bei Bedarf neu zu. Das System verwendet möglicherweise eine vorinstallierte App, die mithilfe von maschinellem Lernen ermittelt, wie wahrscheinlich die Verwendung einer App ist, und Apps den entsprechenden Gruppen zuweist.

Wenn die System-App auf einem Gerät nicht vorhanden ist, sortiert das System die Apps standardmäßig nach der Häufigkeit der Nutzung. Aktiveren Apps werden Buckets mit höherer Priorität zugewiesen, wodurch der App mehr Systemressourcen zur Verfügung stehen. Insbesondere wird durch den Bucket bestimmt, wie häufig die Jobs der App ausgeführt werden und wie oft die App Benachrichtigungen auslösen kann. Diese Einschränkungen gelten nur, wenn das Gerät im Akkubetrieb ist. Während das Gerät geladen wird, gelten diese Einschränkungen nicht.

Die Prioritätsgruppen sind:

  • Aktiv: Die App wird gerade verwendet oder wurde vor Kurzem verwendet.
  • Arbeitssatz: Die App wird regelmäßig verwendet.
  • Häufig: Die App wird oft, aber nicht täglich verwendet.
  • Selten: Die App wird nicht häufig verwendet.
  • Eingeschränkt: Die App verbraucht viele Systemressourcen oder weist unerwünschtes Verhalten auf.

Zusätzlich zu diesen Prioritäts-Buckets gibt es einen speziellen Bucket never für Apps, die installiert, aber nie ausgeführt wurden. Das System schränkt diese Apps stark ein.

Die folgenden Beschreibungen beziehen sich auf den Fall, dass keine Prognose erstellt wird. Wenn hingegen maschinelles Lernen für die Vorhersage des Verhaltens verwendet wird, werden die Buckets nicht anhand der letzten Nutzung, sondern in Erwartung der nächsten Aktionen des Nutzers ausgewählt. So kann beispielsweise eine vor Kurzem verwendete App in den seltenen Bereich eingeordnet werden, weil der Algorithmus vorhersagt, dass die App möglicherweise mehrere Stunden lang nicht verwendet wird.

Aktiv

Eine App wird dem Bucket aktiv zugewiesen, wenn sie verwendet wird, vor Kurzem verwendet wurde oder eine der folgenden Aktionen ausführt:

  • Startet eine Aktivität.
  • Führt einen lang laufenden Dienst im Vordergrund aus.
  • Wird vom Nutzer über eine Benachrichtigung angetippt.

Wenn sich eine App im aktiven Bucket befindet, gelten für die Jobs oder Benachrichtigungen der App keine Einschränkungen.

Apps werden durch Nutzerinteraktionen als aktiv zugewiesen

Unter Android 9 (API-Level 28) und höher wird Ihre App vorübergehend in den Bucket „aktiv“ verschoben, wenn der Nutzer auf bestimmte Weise mit Ihrer App interagiert. Wenn der Nutzer nicht mehr mit Ihrer App interagiert, ordnet das System ihn basierend auf dem bisherigen Nutzungsverlauf einem Bucket zu.

Die folgenden Beispiele zeigen Interaktionen, die dieses Systemverhalten auslösen:

  • Der Nutzer tippt auf eine Benachrichtigung, die von Ihrer App gesendet wird.

  • Der Nutzer interagiert mit einem Dienst im Vordergrund Ihrer App, indem er auf eine Medienschaltfläche tippt.

  • Der Nutzer stellt eine Verbindung zu Ihrer App her, während er mit Android Automotive OS interagiert. Dabei verwendet Ihre App entweder einen Dienst im Vordergrund oder CONNECTION_TYPE_PROJECTION.

Arbeitssatz

Eine App befindet sich im Bucket Arbeitssatz, wenn sie häufig ausgeführt wird, aber nicht aktiv ist. Eine App für soziale Netzwerke, die der Nutzer fast täglich startet, ist beispielsweise wahrscheinlich Teil des Arbeitssatzes. Apps werden auch in den Arbeitssatz-Bucket verschoben, wenn sie indirekt verwendet werden.

Wenn sich eine App im Arbeitssatz befindet, schränkt das System die Ausführung von Jobs und das Auslösen von Benachrichtigungen leicht ein. Weitere Informationen finden Sie unter Einschränkungen der Energieverwaltung.

Häufig

Eine App wird in den Bereich häufig eingeordnet, wenn sie regelmäßig, aber nicht unbedingt täglich verwendet wird. Eine Trainings-Tracking-App, die der Nutzer im Fitnessstudio verwendet, könnte beispielsweise in den häufigen Bucket fallen.

Wenn eine App im Bucket „häufig“ ist, schränkt das System die Ausführung von Jobs und das Auslösen von Weckern stärker ein. Weitere Informationen finden Sie unter Einschränkungen der Energieverwaltung.

Selten

Eine App wird in den Bucket selten eingeordnet, wenn sie nicht oft verwendet wird. Eine Hotel-App, die der Nutzer nur während seines Aufenthalts in diesem Hotel ausführt, könnte beispielsweise in den seltenen Bucket fallen.

Wenn sich eine App im seltenen Bucket befindet, schränkt das System die Ausführung von Jobs und das Auslösen von Weckern stark ein. Außerdem wird die Möglichkeit der App eingeschränkt, eine Internetverbindung herzustellen. Weitere Informationen finden Sie unter Einschränkungen der Energieverwaltung.

Eingeschränkt

Dieser Bucket wurde in Android 12 (API-Level 31) hinzugefügt und hat die niedrigste Priorität und die strengsten Einschränkungen aller Buckets. Das System berücksichtigt das Verhalten Ihrer App, z. B. wie oft Nutzer damit interagieren, um zu entscheiden, ob Ihre App in den eingeschränkten Bereich verschoben wird.

Unter Android 13 (API-Level 33) und höher wird Ihre App vom System in den eingeschränkten Bereich verschoben, es sei denn, sie kommt für eine Ausnahme infrage. Das ist in den folgenden Fällen der Fall:

  • Der Nutzer interagiert eine bestimmte Anzahl von Tagen lang nicht mit Ihrer App. Unter Android 12 (API-Level 31) und 12L (API-Level 32) beträgt die Anzahl der Tage 45. Unter Android 13 wird die Anzahl der Tage auf 8 Tage reduziert.

  • Ihre App ruft innerhalb eines Zeitraums von 24 Stunden eine übermäßige Anzahl von Broadcasts oder Bindungen auf.

Wenn Ihre App vom System in den eingeschränkten Bucket verschoben wird, gelten die folgenden Einschränkungen:

  • Sie können Jobs einmal pro Tag in einer 10-minütigen Batch-Sitzung ausführen. Während dieser Sitzung gruppiert das System die Jobs Ihrer App mit den Jobs anderer Apps.
    • Eingeschränkt Jobs werden nicht automatisch ausgeführt. Es muss mindestens ein anderer Job gleichzeitig ausgeführt werden oder ausstehen.
  • Für Ihre App können weniger Beschleunigte Jobs ausgeführt werden, als wenn das System Ihre App in einen weniger restriktiven Bucket einordnet.
  • Ihre App kann einen Wecker pro Tag auslösen. Dieser Alarm kann entweder ein genauer Alarm oder ein ungenauer Alarm sein.

Ausnahmen vom eingeschränkten Bucket

Die folgenden Arten von Apps werden nicht in den eingeschränkten Bucket verschoben und umgehen den Inaktivitätstrigger auch unter Android 12 und höher:

Prioritäts-Bucket bewerten

So prüfen Sie, welchem Bucket Ihre App zugewiesen ist:

  • Rufen Sie getAppStandbyBucket() an.

  • Führen Sie in einem Terminalfenster den folgenden Befehl aus: 

    adb shell am get-standby-bucket PACKAGE_NAME

Das System drosselt Ihre App, wenn sie in einen App-Standby-Bucket verschoben wird, dessen Wert über STANDBY_BUCKET_ACTIVE (10) liegt.

Best Practices

Wenn Ihre App die Best Practices für Doze und App-Standby befolgt, sind die nachfolgenden Energieverwaltungsfunktionen nicht schwierig. Einige App-Verhaltensweisen, die bisher gut funktioniert haben, können jedoch zu Problemen führen.

  • Versuchen Sie nicht, das System zu manipulieren, damit Ihre App in einen bestimmten Bucket verschoben wird. Die Methode, mit der das System die Priorität festlegt, kann sich ändern und jeder Gerätehersteller kann seine eigene Bucketing-App mit eigenem Algorithmus schreiben. Achten Sie stattdessen darauf, dass sich Ihre App unabhängig von der Kategorie, in der sie sich befindet, angemessen verhält.
  • Wenn eine App keine Launcher-Aktivität hat, wird sie möglicherweise nie in den aktiven Bucket verschoben. Überlegen Sie, Ihre App so umzugestalten, dass sie eine solche Aktivität enthält.

  • Wenn Nutzer nicht mit App-Benachrichtigungen interagieren können, können sie das Angebot der App nicht in den aktiven Bucket verschieben. In diesem Fall sollten Sie einige Benachrichtigungen neu gestalten, damit Nutzer mit ihnen interagieren können. Einige Richtlinien finden Sie in den Designmustern für Benachrichtigungen von Material Design.

  • Wenn die App beim Empfang einer FCM-Nachricht (Firebase Cloud Messaging) mit hoher Priorität keine Benachrichtigung anzeigt, kann der Nutzer nicht mit der App interagieren und sie somit nicht in den aktiven Bucket verschieben. FCM-Nachrichten mit hoher Priorität sind ausschließlich dazu gedacht, dem Nutzer eine Push-Benachrichtigung zu senden. Diese Situation darf also nicht auftreten. Wenn Sie unter 12L (API-Ebene 32) eine FCM-Nachricht fälschlicherweise als „hohe Priorität“ kennzeichnen, obwohl sie keine Nutzerinteraktion auslöst, kann es dazu führen, dass zukünftige Nachrichten herabgestuft werden.

  • Wenn Apps auf mehrere Pakete aufgeteilt sind, befinden sich diese Pakete möglicherweise in verschiedenen Gruppen und haben unterschiedliche Zugriffsebenen. Testen Sie diese Apps mit den Paketen, die verschiedenen Buckets zugewiesen sind, um sicherzustellen, dass die App ordnungsgemäß funktioniert.