App-Standby-Buckets

Android 9 (API-Level 28) und höher unterstützen App Standby Buckets. Mit App Standby-Buckets kann das System die Anfragen von Apps nach Ressourcen priorisieren. Die Priorisierung richtet sich danach, wie oft und wie lange die Apps zuletzt verwendet wurden. Anhand der App-Nutzungsmuster wird jede App in einen von fünf Prioritäts-Buckets eingeordnet. Das System begrenzt die Geräte-Ressourcen, 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 einem 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 es ist, dass die einzelnen Apps verwendet werden, und weist Apps den entsprechenden Buckets zu.

Wenn die System-App auf einem Gerät nicht vorhanden ist, sortiert das System Apps standardmäßig danach, wie lange es her ist, dass sie verwendet wurden. Apps, die aktiver sind, werden Buckets mit höherer Priorität zugewiesen, wodurch mehr Systemressourcen für die App verfügbar sind. Insbesondere bestimmt das Bucket, wie oft die Jobs der App ausgeführt werden und wie oft die App Weckrufe 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.

auf, um herauszufinden, in welchem Bucket sich Ihre App befindet.

Die Prioritätsgruppen sind:

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

Zusätzlich zu diesen Prioritäts-Buckets gibt es einen speziellen Bucket Nie für Apps, die installiert, aber nie ausgeführt wurden. Das System unterliegt strengen Einschränkungen für diese Apps.

Die folgenden Beschreibungen beziehen sich auf den nicht vorhersagenden Fall. Wenn bei der Vorhersage hingegen maschinelles Lernen verwendet wird, um das Verhalten vorherzusagen, werden die Gruppen in Erwartung der nächsten Aktionen des Nutzers ausgewählt und nicht auf Grundlage der letzten Nutzung. Eine kürzlich verwendete App kann beispielsweise in der Kategorie „Selten“ landen, weil maschinelles 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 aus, der lange ausgeführt wird.
  • Der Nutzer tippt in einer Benachrichtigung darauf.

Wenn sich eine App im aktiven Bucket befindet, gelten für die Jobs oder Alarme der App nur minimale Einschränkungen:

  • 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 wurden, sowie Jobs, die von anderen Bibliotheken wie WorkManager oder DownloadManager erstellt wurden.

Durch Nutzerinteraktionen werden Apps als aktiv eingestuft

Unter Android 9 (API-Ebene 28) und höher wird Ihre App vom System vorübergehend in den aktiven Bucket verschoben, wenn der Nutzer auf bestimmte Weise mit Ihrer App interagiert. Nachdem der Nutzer die Interaktion mit Ihrer App beendet hat, wird sie vom System basierend auf dem Nutzungsverlauf in einen Bucket eingeordnet.

Hier einige 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 in Ihrer App, indem er auf eine Medientaste tippt.

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

Arbeitsgruppe

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

Wenn sich eine App im Arbeitsset befindet, unterliegt sie leichten 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

Eine App befindet sich im häufig-Bucket, wenn sie regelmäßig, aber nicht unbedingt jeden Tag verwendet wird. Eine App zur Trainingsaufzeichnung, die der Nutzer im Fitnessstudio verwendet, befindet sich möglicherweise im Bucket „Häufig“.

Wenn sich eine App im Bucket „Häufig“ befindet, unterliegt sie stärkeren Einschränkungen hinsichtlich der Ausführung von Jobs und des Auslösens von Weckern. Weitere Informationen finden Sie unter Ressourcenlimits für die Energieverwaltung.

Selten

Eine App befindet sich im Bucket selten, wenn sie nicht oft verwendet wird. Eine Hotel-App, die der Nutzer nur während seines Aufenthalts in diesem Hotel verwendet, fällt beispielsweise in die Kategorie „Selten“.

Wenn eine App im Bucket „Selten verwendet“ ist, unterliegt sie strengen Einschränkungen hinsichtlich der Ausführung von Jobs und des Auslösens von Weckern. Das System schränkt auch die Möglichkeit der App ein, eine Internetverbindung herzustellen. Weitere Informationen finden Sie unter Ressourcenlimits für die Energieverwaltung.

Eingeschränkt

Dieser Bucket wurde in Android 12 (API-Level 31) hinzugefügt. Er hat die niedrigste Priorität und die meisten 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 sie in den eingeschränkten Bucket platziert werden soll.

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

  • Der Nutzer interagiert über einen bestimmten Zeitraum nicht mit Ihrer App. Unter Android 12 (API‑Level 31) und Android 12L (API‑Level 32) beträgt die Anzahl der Tage 45. In Android 13 wird die Anzahl der Tage auf 8 reduziert.

  • Ihre App ruft innerhalb von 24 Stunden eine übermäßige Anzahl von Broadcasts oder Bindings 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 weiterer Job gleichzeitig ausgeführt werden oder ausstehen. Das kann ein beliebiger anderer Job sein.
  • Ihre App kann weniger beschleunigte Jobs ausführen als wenn das System Ihre App in einen weniger restriktiven Bucket einordnet.
  • Ihre App kann einen Alarm pro Tag auslösen. Dieser Wecker kann entweder ein genauer Wecker oder ein ungenauer Wecker sein.

Ausnahmen vom eingeschränkten Bucket

Die folgenden Arten von Apps sind davon ausgenommen, in den eingeschränkten Bucket zu gelangen, und umgehen den Inaktivitätstrigger, auch unter Android 12 und höher:

Prioritäts-Bucket auswerten

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 einem App Standby Bucket mit einem Wert über STANDBY_BUCKET_ACTIVE (10) platziert wird.

Best Practices

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

  • Versuchen Sie nicht, das System so zu manipulieren, dass Ihre App in eine bestimmte Kategorie eingeordnet wird. Die Methode des Systems zur Priorisierung kann sich ändern und jeder Gerätehersteller kann eine eigene App mit einem eigenen Algorithmus schreiben. Sorgen Sie stattdessen dafür, dass sich Ihre App unabhängig von der Kategorie, in die sie fällt, angemessen verhält.
  • Wenn eine App keine Launcher-Aktivität hat, wird sie möglicherweise nie in den aktiven Bucket verschoben. Erwägen Sie, Ihre App so zu gestalten, dass sie eine solche Aktivität enthält.

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

  • Wenn die App beim Empfang einer FCM-Nachricht mit hoher Priorität 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 vorgesehene Anwendungsfall für FCM-Nachrichten mit hoher Priorität das Senden einer Benachrichtigung an den Nutzer. Diese Situation darf also nicht eintreten. Unter 12L (API-Level 32) und niedriger kann es passieren, dass zukünftige Nachrichten herabgestuft werden, wenn Sie eine FCM-Nachricht fälschlicherweise als „Hohe Priorität“ kennzeichnen, obwohl sie keine Nutzerinteraktion auslöst.

  • 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 sich die App richtig verhält.