App-Standby-Buckets

Android 9 (API-Level 28) und höher unterstützen App-Standby-Buckets. App Standby Buckets helfen dem System, Anfragen von Apps nach Ressourcen basierend darauf zu priorisieren, wie lange die Apps zuletzt und wie oft verwendet werden. Basierend auf den App-Nutzungsmustern wird jede Anwendung in einen von fünf Prioritätsgruppen (Buckets) eingeordnet. Die für die einzelnen Apps verfügbaren Geräteressourcen werden vom System abhängig davon begrenzt, in welchem Bucket sich die App befindet.

Prioritätsgruppen

Das System weist jede Anwendung dynamisch einem Prioritäts-Bucket zu und weist die Anwendungen nach Bedarf neu zu. Das System stützt sich möglicherweise auf eine vorab geladene Anwendung, die mithilfe von maschinellem Lernen bestimmt, wie wahrscheinlich jede Anwendung verwendet wird, und weist Anwendungen den entsprechenden Buckets zu.

Wenn die System-App auf einem Gerät nicht vorhanden ist, sortiert das System Apps standardmäßig danach, wie lange sie zuletzt verwendet wurden. Aktivere Anwendungen werden Buckets zugewiesen, die ihnen eine höhere Priorität geben. 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, wenn das Gerät über den Akku betrieben wird. Während das Gerät geladen wird, gelten diese Einschränkungen nicht.

Die Prioritäts-Buckets sind:

  • Aktiv: Die App wird gerade verwendet bzw. wurde vor Kurzem verwendet.
  • Arbeitsgruppe: Die App wird regelmäßig verwendet.
  • Häufig: Die App wird oft verwendet, aber nicht täglich.
  • Selten: Die App wird nicht häufig verwendet.
  • Eingeschränkt: Die Anwendung beansprucht 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 Anwendungen stark ein.

Die folgenden Beschreibungen beziehen sich auf den nicht vorausschauenden Fall. Wenn bei der Vorhersage hingegen maschinelles Lernen zur Vorhersage des Verhaltens eingesetzt wird, werden Buckets ausgewählt, um die nächsten Aktionen des Nutzers zu berücksichtigen und nicht die jüngsten Nutzungen. Beispielsweise kann eine kürzlich verwendete Anwendung in dem seltenen Bucket landen, weil maschinelles Lernen vorhersagt, dass die Anwendung unter Umständen mehrere Stunden lang nicht verwendet wird.

Aktiv

Eine Anwendung befindet sich im active-Bucket, während sie oder vor Kurzem verwendet wird oder wenn sie eine der folgenden Aktionen ausführt:

  • Startet eine Aktivität.
  • Führt einen lange laufenden Dienst im Vordergrund aus.
  • vom Nutzer in einer Benachrichtigung angetippt wird.

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

Durch die Nutzerinteraktion werden Apps als „aktiv“ gekennzeichnet

Unter Android 9 (API-Level 28) und höher fügt das System die App vorübergehend in den aktiven Bucket, wenn der Nutzer auf bestimmte Weise mit Ihrer App interagiert. Nachdem der Nutzer die Interaktion mit Ihrer Anwendung beendet hat, wird sie vom System auf der Grundlage des Nutzungsverlaufs 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. Dabei verwendet Ihre App entweder einen Dienst im Vordergrund oder CONNECTION_TYPE_PROJECTION.

Arbeitssatz

Eine Anwendung befindet sich im Bucket Arbeitsgruppe, wenn sie häufig ausgeführt wird, aber nicht aktiv ist. Beispielsweise befindet sich eine Social-Media-App, die der Nutzer fast täglich startet, wahrscheinlich im Arbeits-Dataset. Anwendungen werden auch zum Bucket für das Arbeitssatz hochgestuft, wenn sie indirekt verwendet werden.

Wenn sich eine App im Arbeitssatz befindet, schränkt das System die Möglichkeit ein, Jobs auszuführen und Alarme auszulösen. Weitere Informationen finden Sie unter Einschränkungen der Energieverwaltung.

Häufig

Eine Anwendung befindet sich im frequent-Bucket, wenn sie regelmäßig, aber nicht unbedingt täglich verwendet wird. Beispielsweise könnte sich eine Trainings-Tracking-App, die der Nutzer im Fitnessstudio ausführt, in diesem Bucket befinden.

Wenn sich eine Anwendung in einem häufig genutzten Bucket befindet, schränkt das System die Möglichkeit zum Ausführen von Jobs und Auslösen von Alarmen ein. Weitere Informationen finden Sie unter Einschränkungen der Energieverwaltung.

Selten

Eine Anwendung befindet sich im seltenen Bucket, wenn sie nicht oft verwendet wird. Beispielsweise könnte sich eine Hotelanwendung, die der Nutzer nur während des Aufenthalts in diesem Hotel ausführt, in dem seltenen Bucket befinden.

Wenn sich eine Anwendung in dem seltenen Bucket befindet, erzwingt das System strenge Einschränkungen für die Ausführung von Jobs und das Auslösen von Alarmen. Das System schränkt auch die Möglichkeiten der App, eine Verbindung zum Internet herzustellen, ein. Weitere Informationen finden Sie unter Einschränkungen der 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 Anwendung, z. B. wie oft der Nutzer mit ihr interagiert, um zu entscheiden, ob Ihre Anwendung in den eingeschränkten Bucket aufgenommen werden soll.

Unter Android 13 (API-Level 33) und höher platziert das System Ihre App in den folgenden Situationen im eingeschränkten Bucket, sofern Ihre App nicht für eine Ausnahme infrage kommt:

  • 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 wurde die Anzahl der Tage auf 8 reduziert.

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

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

  • Sie können einmal täglich in einer 10-minütigen Batchsitzung Jobs ausführen. Während dieser Sitzung gruppiert das System die Jobs Ihrer Anwendung mit den Jobs anderer Anwendungen.
    • Eingeschränkte Jobs werden nicht allein ausgeführt. Es muss mindestens ein weiterer Job gleichzeitig ausgeführt werden oder ausstehend sein, einschließlich anderer Jobs.
  • Im Vergleich zu einem weniger restriktiven Bucket durch das System kann Ihre Anwendung weniger beschleunigte Jobs ausführen.
  • Deine App kann einen Alarm pro Tag auslösen. Dabei kann es sich um einen genauen Alarm oder einen ungenauen Alarm handeln.

Ausnahmen vom eingeschränkten Bucket

Für die folgenden Arten von Apps ist selbst unter Android 12 und höher keine Aufnahme in den eingeschränkten Bucket zulässig und der Trigger für Inaktivität wird umgangen:

Prioritäts-Bucket auswerten

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 sich in einem Anwendungs-Standby-Bucket befindet, dessen Wert größer als STANDBY_BUCKET_ACTIVE (10) ist.

Best Practices

Wenn Ihre App die Best Practices für den Stromsparmodus und den App-Standby-Modus befolgt, sind die späteren Funktionen zur Energieverwaltung nicht schwierig. Ein App-Verhalten, das zuvor gut funktioniert hat, kann jedoch zu Problemen führen.

  • Versuchen Sie nicht, das System so zu manipulieren, dass sich Ihre App in einem bestimmten Bucket befindet. Die Methode zur Priorisierung des Systems kann sich ändern und jeder Gerätehersteller kann eine eigene Bucketing-App mit einem eigenen Algorithmus schreiben. Sorgen Sie stattdessen dafür, dass Ihre Anwendung unabhängig von dem Bucket, in dem sie sich befindet, korrekt funktioniert.
  • Wenn eine Anwendung keine Launcher-Aktivität hat, wird sie möglicherweise nie zum aktiven Bucket hochgestuft. Erwägen Sie eine Neugestaltung Ihrer App, um eine solche Aktivität zu ermöglichen.

  • Wenn die Nutzer nicht mit App-Benachrichtigungen interagieren können, können sie das Hochstufen der App zum aktiven Bucket nicht auslösen. Erwägen Sie in diesem Fall, einige Benachrichtigungen so umzugestalten, dass Nutzende interagieren können. Einige Richtlinien findest du in den Designmustern für Benachrichtigungen von Material Design.

  • Wenn in der App beim Empfang einer FCM-Nachricht (Firebase Cloud Messaging) mit hoher Priorität keine Benachrichtigung angezeigt wird, kann der Nutzer nicht mit der App interagieren und sie daher zum aktiven Bucket hochstufen. FCM-Nachrichten mit hoher Priorität werden nur dafür verwendet, eine Benachrichtigung an den Nutzer zu senden. Diese Situation darf also nicht eintreten. Wenn Sie auf 12L (API-Ebene 32) und niedriger eine FCM-Nachricht fälschlicherweise mit hoher Priorität markieren, obwohl sie keine Nutzerinteraktion auslöst, kann dies dazu führen, dass zukünftige Nachrichten herabgestuft werden.

  • Wenn Anwendungen auf mehrere Pakete aufgeteilt 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 sicherzustellen, dass die Anwendung ordnungsgemäß funktioniert.