App-Standby-Buckets

Android 9 (API-Level 28) und höher unterstützen App-Standby-Buckets. Mithilfe von App-Standby-Buckets kann das System die Ressourcenanfragen von Apps danach priorisieren, wie kürzlich und wie häufig die Apps verwendet wurden. Basierend auf den Nutzungsmustern der App wird jede App in einen von fünf Prioritäts-Buckets platziert. Das System beschränkt die Geräteressourcen, die jeder App zur Verfügung stehen, je nachdem, in welchem Bucket sich die App befindet.

Prioritäts-Buckets

Das System weist jede App dynamisch einer Prioritätsgruppe zu und weist die Apps bei Bedarf neu zu. Das System kann eine vorinstallierte App verwenden, die mithilfe von maschinellem Lernen die Wahrscheinlichkeit der Nutzung jeder App ermittelt und die Apps den entsprechenden Buckets zuweist.

Wenn die System-App nicht auf einem Gerät vorhanden ist, werden die Apps standardmäßig nach der letzten Verwendung sortiert. Aktivere Apps werden Buckets mit höherer Priorität zugewiesen, sodass der App mehr Systemressourcen zur Verfügung stehen. Der Bucket bestimmt insbesondere, wie oft die Jobs der App ausgeführt werden und wie oft die App Alarme 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äts-Buckets sind:

  • Aktiv: Die App wird gerade 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 zeigt möglicherweise unerwünschtes Verhalten.

Zusätzlich zu diesen Prioritäts-Buckets gibt es einen speziellen never-Bucket 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 nicht vorausschauenden Fall. Wenn die Vorhersage dagegen auf maschinellem Lernen basiert, werden die Buckets im Hinblick auf die nächsten Aktionen des Nutzers ausgewählt und nicht auf Grundlage der letzten Nutzung. Beispielsweise kann eine kürzlich verwendete App in den Bucket „Selten“ verschoben werden, wenn das maschinelle Lernen vorhersagt, dass die App mehrere Stunden lang nicht verwendet wird.

Aktiv

Eine App befindet sich im Bucket Aktiv, wenn sie verwendet wird, vor Kurzem verwendet wurde oder wenn sie eine der folgenden Aktionen ausführt:

  • Startet eine Aktivität.
  • Führt einen Dienst im Vordergrund mit langer Laufzeit aus.
  • Der Nutzer tippt auf eine Benachrichtigung.

Wenn sich eine App im aktiven Bucket befindet, legt das System minimale Einschränkungen für die Jobs oder Alarme der App fest:

  • Ab Android 16 (API-Level 36) haben Hintergrundjobs ein großzügiges Laufzeitkontingent, wenn sie von einer App im aktiven Bucket gestartet werden. Dazu gehören Jobs, die direkt mit JobScheduler geplant werden, sowie Jobs, die von anderen Bibliotheken wie WorkManager oder DownloadManager erstellt werden.

Nutzerinteraktion weist Apps als aktiv zu

Wenn der Nutzer unter Android 9 (API-Level 28) und höher auf bestimmte Weise mit Ihrer App interagiert, wird sie vom System vorübergehend in den aktiven Bucket verschoben. Wenn der Nutzer nicht mehr mit deiner App interagiert, wird sie vom System anhand des Nutzungsverlaufs in einen Bucket verschoben.

Hier einige Beispiele für Interaktionen, die dieses Systemverhalten auslösen:

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

  • Der Nutzer interagiert mit einem Dienst im Vordergrund in 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, wobei Ihre App entweder einen Dienst im Vordergrund oder CONNECTION_TYPE_PROJECTION verwendet.

Arbeits-Dataset

Eine App befindet sich im Bucket Arbeitsgruppe, wenn sie häufig ausgeführt wird, aber nicht aktiv ist. Eine Social-Media-App, die der Nutzer fast täglich startet, befindet sich beispielsweise wahrscheinlich im Arbeitssatz. Apps werden auch in den Bucket „Working Set“ verschoben, wenn sie indirekt verwendet werden.

Wenn sich eine App im Working Set befindet, gelten für sie milde Einschränkungen hinsichtlich der Ausführung von Jobs und des Auslösens von Alarmen. Weitere Informationen finden Sie unter Ressourcenlimits für die Energieverwaltung.

Häufig kontaktiert

Eine App befindet sich im Bucket Häufig, wenn sie regelmäßig, aber nicht unbedingt täglich verwendet wird. Eine App zur Trainingsaufzeichnung, die der Nutzer im Fitnessstudio ausführt, könnte sich beispielsweise im Bucket „Häufig“ befinden.

Wenn sich eine App im Bucket „Häufig“ befindet, gelten strengere Einschränkungen für die Ausführung von Jobs und das Auslösen von Alarmen. Weitere Informationen finden Sie unter Ressourcenlimits für die Energieverwaltung.

Selten

Eine App befindet sich im Bucket Selten, wenn sie nicht oft verwendet wird. Beispiel: Eine Hotel-App, die der Nutzer nur während seines Aufenthalts in diesem Hotel ausführt, könnte sich im Bucket „Selten“ befinden.

Wenn sich eine App im Bucket „Selten“ befindet, gelten strenge Einschränkungen für die Ausführung von Jobs und das Auslösen von Alarmen. Das System schränkt auch die Möglichkeit der App ein, eine Verbindung zum Internet herzustellen. Weitere Informationen finden Sie unter Ressourcenlimits für die Energieverwaltung.

Eingeschränkt

Dieser Bucket, der in Android 12 (API-Level 31) hinzugefügt wurde, hat die niedrigste Priorität und die höchsten Einschränkungen aller Buckets. Das System berücksichtigt das Verhalten Ihrer App, z. B. wie oft der Nutzer mit ihr interagiert, um zu entscheiden, ob Ihre App in den eingeschränkten Bucket verschoben werden soll.

Unter Android 13 (API‑Level 33) und höher wird Ihre App, sofern sie nicht für eine Ausnahme infrage kommt, in den folgenden Situationen in den eingeschränkten Bucket verschoben:

  • Der Nutzer interagiert eine bestimmte Anzahl von Tagen 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 reduziert.

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

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

  • Sie können Jobs einmal pro Tag in einer 10-minütigen Batchsitzung ausführen. Während dieser Sitzung gruppiert das System die Jobs Ihrer App mit den Jobs anderer Apps.
    • Eingeschränkte Jobs werden nicht automatisch ausgeführt. Es muss mindestens ein anderer Job gleichzeitig ausgeführt werden oder ausstehen. Dies kann ein beliebiger anderer Job sein.
  • Ihre App kann weniger Express-Jobs ausführen als wenn das System Ihre App in einem weniger restriktiven Bucket platziert.
  • Ihre App kann einen Alarm pro Tag aufrufen. Dieser Alarm kann entweder ein exakter Alarm oder ein ungenauer Wecker sein.

Ausnahmen vom eingeschränkten Bucket

Die folgenden App-Typen werden nicht in den eingeschränkten Bucket verschoben und umgehen den Inaktivitäts-Trigger, auch unter Android 12 und höher:

Prioritäts-Bucket bewerten

So finden Sie heraus, 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 mit einem Wert größer als STANDBY_BUCKET_ACTIVE (10) platziert wird.

Best Practices

Wenn Sie die Best Practices für den Stromsparmodus und den App-Standby befolgen, sind die späteren Funktionen zur Energieverwaltung nicht schwierig. Einige App-Verhaltensweisen, die zuvor gut funktioniert haben, können jedoch Probleme verursachen.

  • Versuche nicht, das System so zu manipulieren, dass deine App in einen bestimmten Bucket eingeordnet wird. Die Methode des Systems zur Priorisierung kann sich ändern und jeder Gerätehersteller kann eine eigene App für die Einteilung in Buckets mit einem eigenen Algorithmus schreiben. Sorge stattdessen dafür, dass sich deine App unabhängig vom Bucket, in dem sie sich befindet, angemessen verhält.
  • Wenn eine App keine Launcher-Aktivität hat, wird sie möglicherweise nie in den aktiven Bucket verschoben. Sie sollten Ihre App so umgestalten, dass sie eine solche Aktivität enthält.

  • Wenn Nutzer nicht mit App-Benachrichtigungen interagieren können, können sie die App nicht in den aktiven Bucket verschieben. In diesem Fall sollten Sie einige Benachrichtigungen, die Nutzern Interaktionen ermöglichen, neu gestalten. Richtlinien finden Sie in den Designmustern für Benachrichtigungen von Material Design.

  • Wenn die App beim Empfang einer RemoteNotification-Firebase Cloud Messaging-Nachricht (FCM) keine Benachrichtigung anzeigt, kann der Nutzer nicht mit der App interagieren und sie somit nicht in den aktiven Bucket verschieben. Tatsächlich ist der einzige Verwendungszweck für RemoteNotification, eine Benachrichtigung an den Nutzer zu senden. Diese Situation darf also nicht auftreten. Für die Verwendung dieser Nachrichtentypen gilt eine Richtlinie: ein 20-sekündiges Ausführungsfenster, das auf die ursprüngliche Benachrichtigung zurückgreift. Es gibt keine Einschränkungen, wenn die App im Vordergrund ausgeführt wird oder der Nutzer die Ausführung im Hintergrund erlaubt.

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