App-Standby-Buckets

Android 9 (API-Level 28) und höher unterstützen App-Standby-Buckets. Mit App-Standby-Buckets kann das System Ressourcenanfragen von Anwendungen anhand der Aktualität und Häufigkeit der Anwendungen priorisieren. Jede Anwendung wird je nach Anwendungsmuster in einen von fünf Prioritäts-Buckets eingeordnet. Das System begrenzt die für jede Anwendung verfügbaren Geräteressourcen anhand des Buckets, in dem sich die Anwendung befindet.

Prioritäts-Buckets

Das System weist jeder Anwendung dynamisch einen Prioritäts-Bucket zu und weist die Anwendungen nach Bedarf neu zu. Das System kann sich auf eine vorab geladene Anwendung verlassen, die mithilfe von maschinellem Lernen ermittelt, wie wahrscheinlich es ist, dass eine Anwendung verwendet wird, und Anwendungen den entsprechenden Buckets zuweist.

Wenn die System-App auf einem Gerät nicht vorhanden ist, sortiert das System Apps standardmäßig nach ihrer letzten Nutzung. Aktivere Anwendungen werden Buckets zugewiesen, die ihnen eine höhere Priorität einräumen. Dadurch stehen der Anwendung mehr Systemressourcen zur Verfügung. Der Bucket bestimmt insbesondere, wie häufig die Jobs der Anwendung ausgeführt werden und wie oft die Anwendung Alarme auslösen kann. Diese Einschränkungen gelten nur, während 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 verwendet oder wurde vor Kurzem verwendet.
  • Arbeitssatz: Die App wird regelmäßig verwendet.
  • Häufig: Die App wird häufig genutzt, aber nicht täglich.
  • Selten: Die App wird nicht häufig verwendet.
  • Eingeschränkt: Die Anwendung verbraucht viele Systemressourcen oder weist möglicherweise ein unerwünschtes Verhalten auf.

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

Die folgenden Beschreibungen beziehen sich auf den nicht vorhersehbaren Fall. Wenn bei der Vorhersage hingegen maschinelles Lernen zur Vorhersage des Verhaltens verwendet wird, werden Buckets in Erwartung der nächsten Aktionen des Nutzers und nicht basierend auf der jüngsten Nutzung ausgewählt. 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 Anwendung befindet sich im active-Bucket, wenn sie verwendet wird, vor Kurzem verwendet wird oder eine der folgenden Aktionen ausführt:

  • Startet eine Aktivität.
  • Führt einen lange laufenden Dienst im Vordergrund aus.
  • Wenn der Nutzer in einer Benachrichtigung darauf tippt.

Wenn sich eine Anwendung im aktiven Bucket befindet, legt das System keine Einschränkungen für die Jobs oder Alarme der Anwendung fest.

Durch Nutzerinteraktion werden Apps als aktiv zugewiesen

Wenn der Nutzer unter Android 9 (API-Level 28) und höher mit Ihrer App interagiert, platziert das System Ihre App vorübergehend im aktiven Bucket. 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 Ihre App sendet.

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

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

Arbeitssatz

Eine Anwendung befindet sich im Bucket Working set, 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. Anwendungen werden auch in den Bucket für den Arbeitssatz hochgestuft, 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 Anwendung befindet sich im Bucket frequent, wenn sie regelmäßig, aber nicht unbedingt jeden Tag verwendet wird. Beispielsweise könnte sich eine Trainingsverfolgungs-App, die der Nutzer im Fitnessstudio ausführt, im Bucket für häufige Aktivitäten befinden.

Wenn sich eine Anwendung im häufigen Bucket befindet, gelten strengere Einschränkungen für die Fähigkeit des Systems, Jobs auszuführen und Alarme auszulösen. Weitere Informationen finden Sie unter Einschränkungen der Energieverwaltung.

Selten

Eine Anwendung befindet sich im selten-Bucket, wenn sie nicht oft verwendet wird. In diesem seltenen Bucket kann sich beispielsweise eine Hotel-App befinden, die der Nutzer nur während seines Aufenthalts in diesem Hotel ausführt.

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 schränkt das System die Fähigkeit der App ein, eine Verbindung zum Internet herzustellen. Weitere Informationen finden Sie unter Einschränkungen der Energieverwaltung.

Eingeschränkt

Dieser Bucket, der in Android 12 (API-Level 31) hinzugefügt wurde, hat von allen Buckets die niedrigste Priorität und die höchsten Einschränkungen. 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 über 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. 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 Ihre Anwendung vom System in den eingeschränkten Bucket verschoben wird, 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änkte Jobs werden nicht automatisch ausgeführt. Es muss mindestens ein weiterer Job gleichzeitig ausgeführt werden oder ausstehend sein. Dies kann auch ein beliebiger anderer Job sein.
  • Ihre Anwendung kann weniger schnelle Jobs ausführen als wenn das System Ihre Anwendung in einem weniger restriktiven Bucket platziert.
  • Deine App kann einen Wecker pro Tag auslösen. Dieser Alarm kann entweder ein exakter Alarm oder ein ungenauer Alarm sein.

Ausnahmen vom eingeschränkten Bucket

Die folgenden App-Typen sind von der Eingabe in den eingeschränkten Bucket ausgenommen und umgehen den Inaktivitätstrigger, auch unter Android 12 und höher:

Prioritäts-Bucket bewerten

Führen Sie einen der folgenden Schritte aus, um zu prüfen, welchem Bucket Ihre Anwendung zugewiesen ist:

  • Rufen Sie getAppStandbyBucket() auf.

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

    adb shell am get-standby-bucket PACKAGE_NAME

Das System drosselt Ihre Anwendung, wenn sie in einem App-Standby-Bucket platziert wird, dessen Wert größer als STANDBY_BUCKET_ACTIVE (10) ist.

Best Practices

Wenn Ihre Anwendung die Best Practices für den Stromsparmodus und den Anwendungs-Standby-Modus befolgt, lassen sich die späteren Funktionen zur Energieverwaltung problemlos nutzen. Allerdings können einige App-Verhaltensweisen, die zuvor gut funktioniert haben, zu Problemen führen.

  • Versuchen Sie nicht, das System so zu manipulieren, dass die Anwendung in einen bestimmten Bucket platziert wird. Die Prioritätsmethode des Systems kann sich ändern und jeder Gerätehersteller schreibt möglicherweise seine eigene Bucketing-Anwendung mit einem eigenen Algorithmus. Stattdessen sollten Sie dafür sorgen, dass sich Ihre Anwendung unabhängig davon, in welchem Bucket sie sich befindet, ordnungsgemäß verhält.
  • Wenn eine App keine Launcher-Aktivität hat, wird sie möglicherweise nie in den aktiven Bucket hochgestuft. Erwägen Sie, Ihre App umzugestalten, um solche Aktivitäten zu ermöglichen.

  • 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 daher zum aktiven Bucket hochstufen. Tatsächlich ist die einzige vorgesehene Verwendung von FCM-Nachrichten mit hoher Priorität darin, eine Benachrichtigung an den Nutzer zu senden. Diese Situation darf also nicht eintreten. Wenn Sie auf 12L (API-Level 32) und niedriger eine FCM-Nachricht fälschlicherweise mit hoher Priorität markieren, obwohl sie keine Nutzerinteraktion auslöst, kann dies für zukünftige Nachrichten eine geringere Priorität einnehmen.

  • Wenn Anwendungen auf mehrere Pakete verteilt sind, können sich diese Pakete in verschiedenen Buckets befinden und unterschiedliche Zugriffsebenen haben. Testen Sie diese Anwendungen mit den Paketen, die verschiedenen Buckets zugewiesen sind, um zu prüfen, ob die Anwendung ordnungsgemäß funktioniert.