Ein durchschnittlicher Android-Nutzer installiert mehr als 50 Apps auf seinen Geräten. Die Zahl nimmt zu, wenn die RAM-Stufe der Geräte zunimmt. Eine beträchtliche Anzahl dieser Apps wird jedoch über einen langen Zeitraum nicht vom Nutzer verwendet.
Beim App-Ruhezustand werden Apps, die der Nutzer einige Monate lang nicht verwendet hat, in den Ruhezustand versetzt. Das funktioniert ähnlich wie der automatische Widerruf von Berechtigungen. Dadurch wird die App beendet und in einen Zustand versetzt, in dem sie nicht mehr für die Leistung, sondern für den Speicherplatz optimiert wird. Die automatische Widerrufsfunktion für Berechtigungen ist ebenfalls mit diesem Status verknüpft und hat dieselbe Ausnahmeeinstellung in den Einstellungen. Bei einer erzwungenen Beendigung einer App werden keine Jobs oder Benachrichtigungen im Hintergrund ausgeführt und es können keine Push-Benachrichtigungen gesendet werden. Wenn der Nutzer die App wieder verwendet, wird der Ruhemodus beendet und Jobs, Benachrichtigungen und Warnungen werden wieder wie gewohnt ausgeführt. Alle Jobs, Benachrichtigungen und Warnungen, die vor dem Ruhemodus der App geplant wurden, müssen neu geplant werden.
Wenn OEMs die Plattform ändern, kann dies zu Konflikten mit der Implementierung des App-Ruhemodus führen. Zum Beispiel
- Wenn Sie die Definition der App-Nutzung ändern oder Möglichkeiten zum Aufwecken einer App einführen, die nicht in AOSP enthalten sind, kann dies die Genauigkeit des App-Ruhemodus beeinträchtigen.
- Ein proprietärer Einschränkungsmechanismus eines OEMs, der dem App-Ruhemodus ähnelt, kann einen ähnlichen Zweck erfüllen. Beides kann zwar existieren, es kann sich aber auch überschneiden.
Der CDD enthält eine neue Reihe von Anforderungen für Änderungen, die auf der App-Nutzung basieren, ähnlich wie die bestehende Anforderung 3.5.1. Für den App-Ruhemodus gelten folgende Anforderungen:
Der Framework-Code befindet sich hier:
- repo: Plattform/Frameworks/Basis
- Verzeichnis: services/core/java/com/android/server/apphibernation
Die Richtlinienlogik befindet sich in:
- repo: platform/packages/modules/Permission
- Verzeichnis: PermissionController/src/com/android/permissioncontroller/hibernation
Gesamtarchitektur
Der App-Ruhezustands-Systemdienst optimiert die selten verwendeten Apps eines Nutzers für den Speicher und verhindert, dass diese Apps im Hintergrund ausgeführt werden. Um diese Ergebnisse zu erzielen, gehen wir beim Energiesparmodus einer App so vor:
- Berechtigungen automatisch widerrufen
- Beenden der App erzwingen
- ODEX- und VDEX-Dateien löschen
- App-Cache löschen
Unser Ziel ist es, den Ruhemodus als reversible Aktion zu implementieren, damit die App für den Nutzer weiterhin über den Launcher und andere Oberflächen verfügbar ist und die App-Daten intakt bleiben. Beim Starten der App wird sie aus dem Status der erzwungenen Beendigung wiederhergestellt und die Erstellung der ODEX- und VDEX-Datei wie gewohnt fortgesetzt.
Das geplante Design konzentriert sich auf zwei Hauptteile:
- Festlegen, wann ein Paket in den Ruhemodus versetzt werden soll
- Energiesparmodus-Paket optimieren
Ein neuer Systemdienst, AppHibernationService
, und ein Jobdienst, AppHibernationJobService,
, inPermissionController
steuern die gesamte Entscheidungsfindung und Logik.
Die Entscheidung, wann ein Paket in den Ruhemodus versetzt werden soll, wird hauptsächlich von UsageStatsService
gesteuert und in PermissionController
von AppHibernationJobService
. Diese Richtlinienlogik befindet sich in PermissionController
, damit wir sie dynamisch über Mainline aktualisieren können. Außerdem planen wir, ein neues Signal hinzuzufügen: die Komponentennutzung. Damit soll die Nutzung der Komponenten des Pakets (z. B. Dienste, Inhaltsanbieter) als neuer Messwert in UsageStatsService
erfasst werden.
Bei der Optimierung eines Pakets werden die tatsächlichen Einsparungen und Optimierungen erzielt. AppHibernationService
kommuniziert mit verschiedenen Teilen des Systems, um das Paket anzuhalten, Cache-Daten zu löschen, ART-Artefakte zu löschen usw.
Der Widerruf von Berechtigungen wird direkt über AppHibernationJobService
initiiert, um die Funktion zum automatischen Widerruf auf Geräten mit Android 11 und niedriger zu erhalten.
Nutzererfahrung
Der Nutzer erhält Informationen und kann festlegen, welche Apps in den Ruhemodus versetzt werden können.
Ähnlich wie beim automatischen Widerruf erhält der Nutzer eine Benachrichtigung darüber, welche Apps im Ruhemodus sind. Er kann dann direkt über die Benachrichtigung die Einstellungen aufrufen, um die App entweder zu öffnen und aus dem Ruhemodus zu entfernen oder die nicht verwendete App bei Bedarf zu löschen.
Wir unterstützen weiterhin die Absicht des Entwicklers, den Nutzer mit dem bestehenden Ausnahme-Intent zum automatischen Widerrufen von Berechtigungen um eine Ausnahme vom Ruhezustand zu bitten.
Abwärtskompatibilität
Funktionen für den Ruhemodus sind ab Android 12 verfügbar. Diese Funktion konnte in früheren Versionen nicht funktionieren, da die Plattformkomponenten (z. B. der neue Systemdienst) nicht vorhanden sind. Die automatische Widerrufsfunktion funktioniert weiterhin wie bei den früheren Betriebssystemversionen.
Ab Android 12 wird zur Gewährleistung der Abwärtskompatibilität auf der Seite der App unter Apps & Benachrichtigungen in den Einstellungen eine Ein/Aus-Schaltfläche für den Ruhezustand hinzugefügt. Die ursprüngliche Ein/Aus-Schaltfläche für die automatische Aufhebung befindet sich im Untermenü Berechtigungen. Mit dieser Ein/Aus-Schaltfläche wird die allgemeine Ausnahme für die App-Ruhezustandsfunktion gesteuert.
Personalisierung
Ein Teil der Implementierung ist Teil einer modularen Systemkomponente. Wir raten Partnern daher davon ab, die Funktion zu ändern. Partner können stattdessen ähnliche Funktionen implementieren, solange sie die CDD-Anforderungen einhalten.
Die App-Ruhezeit sollte für alle Apps, die auf Android 11 oder höher ausgerichtet sind, standardmäßig aktiviert sein. Dies entspricht dem automatischen Widerruf von Berechtigungen. Auch wenn die Einstellung selbst aktiviert ist, kann die Implementierung der App-Ruhezustandsfunktion zwischen Apps, die auf Android 11 und Android 12 ausgerichtet sind, variieren. Genauer gesagt funktioniert der App-Ruhezustand nur für Apps, die auf Android 11 ausgerichtet sind. Für Apps, die auf Android 12 ausgerichtet sind, erfolgt der Ruhezustand im Wesentlichen.
Möglicherweise implementieren OEMs auch eine ähnliche Funktion. Diese Funktionen sind jedoch auf einen viel kürzeren Zeitrahmen für Akkuoptimierungen ausgerichtet, die OEM-spezifisch sein können. Ähnliche Funktionen zur App-Einschränkung, die von OEMs entwickelt wurden, können mit dem App-Ruhezustandssystem zusammen verwendet werden, solange sie die im CDD definierten Kriterien erfüllen.
Testen
Für den App-Ruhezustand werden CTS und Unittests durchgeführt, um sicherzustellen, dass sie ordnungsgemäß funktioniert.
AutoRevokeTest
AppHibernationIntegrationTest