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, werden Apps standardmäßig nach der Häufigkeit ihrer Nutzung sortiert. 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 in Erwartung der nächsten Aktionen des Nutzers ausgewählt und nicht anhand der letzten Nutzung. Beispielsweise kann eine kürzlich verwendete Anwendung in dem seltenen Bucket landen, weil maschinelles Lernen vorhersagt, dass die Anwendung 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.
  • Wenn der Nutzer in einer Benachrichtigung darauf tippt

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. Nachdem der Nutzer die Interaktion mit Ihrer Anwendung beendet hat, wird sie vom System basierend auf dem Nutzungsverlauf in einen Bucket verschoben.

Im Folgenden finden Sie Beispiele für 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. Beispielsweise gehört eine Social-Media-App, die der Nutzer fast täglich startet, wahrscheinlich in der Arbeitsumgebung. Apps werden auch in den Arbeitssatz-Bucket verschoben, wenn sie indirekt verwendet werden.

Wenn sich eine Anwendung im Arbeitssatz befindet, erzwingt das System leichte Einschränkungen für die Fähigkeit, Jobs auszuführen und Alarme auszulösen. 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 Anwendung befindet sich im selten-Bucket, 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 Anwendung im seltenen Bucket befindet, unterliegt das System strenge Einschränkungen für die Fähigkeit, Jobs auszuführen und Alarme auszulösen. 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 Anwendung, z. B. wie oft der Nutzer mit ihr interagiert, um zu entscheiden, ob die Anwendung in den eingeschränkten Bucket aufgenommen werden soll.

Unter Android 13 (API-Level 33) und höher platziert das System Ihre Anwendung in den folgenden Situationen in den eingeschränkten Bucket, sofern für Ihre Anwendung keine Ausnahme gilt:

  • 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. Mit Android 13 wird die Anzahl der Tage auf 8 reduziert.

  • Ihre Anwendung ruft während eines 24-Stunden-Zeitraums übermäßig viele Übertragungen oder Bindungen auf.

Wenn Ihr System Ihre App in den eingeschränkten Bucket verschiebt, gelten die folgenden Einschränkungen:

  • Sie können in einer 10-minütigen Batch-Sitzung einmal pro Tag Jobs ausführen. Während dieser Sitzung gruppiert das System die Jobs Ihrer Anwendung mit denen anderer Anwendungen.
    • 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.
  • Deine 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() auf.

  • 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 so zu manipulieren, dass die Anwendung in einen bestimmten Bucket platziert 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 die Nutzer nicht mit App-Benachrichtigungen interagieren können, können sie die Hochstufung der Anwendung zum aktiven Bucket nicht auslösen. Ziehen Sie in diesem Fall in Betracht, einige Benachrichtigungen neu zu gestalten, damit Nutzende 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 Anwendungen auf mehrere Pakete verteilt sind, können sich diese Pakete in verschiedenen Buckets befinden und unterschiedliche Zugriffsebenen haben. Testen Sie diese Apps mit den Paketen, die verschiedenen Buckets zugewiesen sind, um sicherzustellen, dass die App ordnungsgemäß funktioniert.