Akkunutzung Ihrer App mit dem Android Vitals-Messwert für Wakelocks optimieren

Die Akkulaufzeit ist ein wichtiger Aspekt der Nutzerfreundlichkeit und Wake Locks spielen dabei eine große Rolle. Verwenden Sie sie übermäßig? In diesem Blogpost erfahren Sie, was Wake Locks sind, welche Best Practices für die Verwendung gelten und wie Sie das Verhalten Ihrer eigenen App mit dem Play Console-Messwert besser nachvollziehen können.

Übermäßige Verwendung von Teil-Wakelocks in Android Vitals

In der Play Console wird jetzt die Akkuentladung überwacht. Dabei wird der übermäßige Gebrauch von Teil-Wakelocks als wichtiger Leistungsindikator betrachtet.

Diese Funktion unterstreicht die Bedeutung der Akkueffizienz neben den vorhandenen Stabilitätsindikatoren für Hauptmesswerte: übermäßige von Nutzern wahrgenommene Abstürze und ANRs. Wir haben einen Grenzwert für unerwünschtes Verhalten bei übermäßigen Wakelocks definiert. Ab dem 1. März 2026 kann es sein, dass wir Titel, die diesen Qualitätsgrenzwert nicht erreichen, von prominenten Oberflächen wie Empfehlungen ausschließen. In einigen Fällen wird in Ihrem Store-Eintrag eine Warnung angezeigt, um Nutzer darauf hinzuweisen, dass Ihre App möglicherweise zu einem übermäßigen Akkuverbrauch führt.

Die Warnung zu übermäßigen Wakelocks in der Übersicht über Android Vitals.

Bei Mobilgeräten gilt die Android Vitals-Messwert für nicht ausgenommene Wakelocks, die abgerufen werden, während der Bildschirm ausgeschaltet ist und die App im Hintergrund ausgeführt wird oder einen Vordergrunddienst ausführt. Die Verwendung von Teil-Wakelocks gilt in Android Vitals als übermäßig, wenn:

• Wake Locks werden innerhalb eines Zeitraums von 24 Stunden mindestens zwei Stunden lang gehalten.
• Sie betrifft durchschnittlich über 28 Tage mehr als 5% der Sitzungen Ihrer App.

Von den nutzerinitiierten APIs audio, location und JobScheduler erstellte Wake Locks sind von der Wake Lock-Berechnung ausgenommen.

Wakelocks

Ein Wake Lock ist ein Mechanismus, mit dem eine App die CPU eines Geräts auch dann weiter ausführen kann, wenn der Nutzer nicht aktiv mit dem Gerät interagiert. 

Bei einem Teil-Wakelock bleibt die CPU aktiv, auch wenn das Display ausgeschaltet ist. So wird verhindert, dass die CPU in den Energiesparmodus wechselt. Bei einem vollständigen Wakelock bleiben sowohl das Display als auch die CPU aktiv.

Es gibt zwei Methoden, um partielle Wake Locks zu erhalten:

• Die App ruft das Wake Lock manuell ab und gibt es wieder frei. Dazu werden PowerManager-APIs für einen bestimmten Anwendungsfall verwendet. Häufig wird das Wake Lock in Verbindung mit einem Dienst im Vordergrund abgerufen. Das ist eine Plattform-Lifecycle-API, die für den für Nutzer sichtbaren Betrieb vorgesehen ist.
• Alternativ wird das Wake Lock von einer anderen API abgerufen und der App aufgrund der Verwendung der API zugeordnet. Weitere Informationen finden Sie im Abschnitt zu Best Practices.

Wake Locks sind zwar für Aufgaben wie das Abschließen eines vom Nutzer initiierten Downloads einer großen Datei erforderlich, ihre übermäßige oder unsachgemäße Verwendung kann jedoch zu einem erheblichen Akkuverbrauch führen. Es gibt Fälle, in denen Apps Wake Locks stundenlang halten oder nicht richtig freigeben. Dies führt zu Nutzerbeschwerden über einen erheblichen Akkuverbrauch, auch wenn sie nicht mit der App interagieren.

Best Practices für die Verwendung von Wake Locks

Bevor wir uns ansehen, wie Sie die übermäßige Verwendung von Wake Locks debuggen, sollten Sie die Best Practices für Wake Locks beachten. 

Beantworten Sie diese vier wichtigen Fragen.

1. Haben Sie alternative Wake Lock-Optionen in Betracht gezogen?

Bevor Sie einen manuellen partiellen Wake Lock in Betracht ziehen, folgen Sie diesem Entscheidungsflussdiagramm:

Flussdiagramm zur Entscheidung, wann ein Wake Lock manuell abgerufen werden sollte

1. Muss das Display eingeschaltet bleiben?
   • Ja: Siehe stattdessen die Dokumentation zu Display immer an.
2. Wird in der Anwendung ein Vordergrunddienst ausgeführt?
   • Nein. Sie müssen kein Wake Lock manuell abrufen.
3. Ist es schädlich für die Nutzererfahrung, wenn das Gerät in den Ruhezustand wechselt?
   • Nein: Wenn Sie beispielsweise eine Benachrichtigung aktualisieren, nachdem das Gerät aktiviert wurde, ist kein Wake Lock erforderlich.
   • Ja: Wenn es wichtig ist, dass das Gerät nicht in den Ruhezustand wechselt, z. B. bei laufender Kommunikation mit einem externen Gerät, fahre fort.
4. Gibt es bereits eine API, die das Gerät für Sie aktiv hält?
   • In der Dokumentation Von anderen APIs erstellte Wake Locks identifizieren finden Sie Informationen dazu, wie Sie Szenarien identifizieren, in denen Wake Locks von anderen APIs wie LocationManager erstellt werden.
   • Wenn keine APIs vorhanden sind, fahren Sie mit der letzten Frage fort.
5. Wenn Sie alle diese Fragen beantwortet haben und zu dem Schluss gekommen sind, dass es keine Alternative gibt, sollten Sie mit dem manuellen Abrufen eines Wake Locks fortfahren.

2. Benennen Sie das Wakelock richtig?

Wenn Sie Wake Locks manuell abrufen, ist eine korrekte Benennung für die Fehlerbehebung wichtig:

• Lassen Sie alle personenidentifizierbaren Informationen wie E‑Mail-Adressen im Namen weg. Wenn personenbezogene Daten erkannt werden, wird das Wake Lock als _UNKNOWN protokolliert, was die Fehlersuche erschwert.
• Benennen Sie Ihren Wake Lock nicht programmatisch mit Klassen- oder Methodennamen, da diese von Tools wie Proguard verschleiert werden können. Verwenden Sie stattdessen einen fest codierten String.
• Fügen Sie keine Zähler oder eindeutigen Kennungen zu Wake Lock-Tags hinzu. Dasselbe Tag sollte jedes Mal verwendet werden, wenn der Wake Lock ausgeführt wird, damit das System die Nutzung nach Namen zusammenfassen kann und sich ungewöhnliches Verhalten leichter erkennen lässt.

3. Wird die erworbene Wake Lock immer freigegeben?

Wenn Sie einen Wake Lock manuell abrufen, muss der Wake Lock immer freigegeben werden. Wenn Sie ein Wake Lock nicht freigeben, kann dies zu einem erheblichen Akkuverbrauch führen. 

Wenn beispielsweise während der Ausführung von processingWork() eine nicht abgefangene Ausnahme ausgelöst wird, wird release() möglicherweise nie aufgerufen. Stattdessen können Sie einen try-finally-Block verwenden, um sicherzustellen, dass das Wake Lock freigegeben wird, auch wenn eine Ausnahme auftritt.

Außerdem können Sie dem Wake Lock ein Zeitlimit hinzufügen, damit es nach einem bestimmten Zeitraum freigegeben wird und nicht unbegrenzt gehalten wird.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Kannst du die Häufigkeit des Aufweckens reduzieren?

Bei regelmäßigen Datenanfragen ist es für die Akkuoptimierung entscheidend, wie oft Ihre App das Gerät aktiviert. Beispiele für die Reduzierung der Aufwachhäufigkeit:

• WorkManager:Erhöhe das periodische Intervall in PeriodicWorkRequests.
• SensorManager:Verwenden Sie Batching, indem Sie beim Registrieren des Listeners maxReportLatencyMs angeben.
• Anbieter für kombinierte Standortbestimmung
  :
  • Reduzieren Sie die Häufigkeit des Abrufs von Standortdaten, indem Sie getLastLocation für den zuletzt im Cache gespeicherten Standort verwenden.
  • Verwenden Sie setPriority(PRIORITY_PASSIVE) für eine weniger akkuintensive Aktualisierungsmethode.
  • Außerdem können Sie den Mechanismus für die Batchverarbeitung von Standorten nutzen, indem Sie mit setMinUpdateIntervalMillis ein Mindestaktualisierungsintervall festlegen.

Weitere Informationen finden Sie in der Dokumentation zu Best Practices für Wake Locks.

Übermäßige Wakelock-Nutzung beheben

Auch wenn Sie es nicht beabsichtigen, kann es zu einer übermäßigen Nutzung von Wake Locks kommen. Wenn Ihre App in der Play Console gekennzeichnet ist, können Sie sie so debuggen:

Erste Identifizierung mit der Play Console

Das Dashboard „Übermäßige teilweise Wakelocks“ von Android Vitals enthält Aufschlüsselungen der nicht ausgenommenen Wakelock-Namen, die mit Ihrer App verknüpft sind. Außerdem werden die betroffenen Sitzungen und Zeiträume angezeigt. Erinnerung, anhand der Dokumentation zu prüfen, ob der Wake Lock-Name von der App oder von einer anderen API gehalten wird.

Das Dashboard „Übermäßige Teil-Wakelocks“ von Android Vitals, heruntergescrollt zum Abschnitt „Aufschlüsselungen“, in dem Tags für übermäßige Wakelocks angezeigt werden.

Debuggen von übermäßigen Wake Locks, die von Workern/Jobs gehalten werden

Sie können Worker-Wake Locks anhand dieses Wake Lock-Namens identifizieren:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Die vollständige Liste der Varianten von Namen für Wake Locks, die vom Worker gehalten werden, ist in der Dokumentation verfügbar. Zur Fehlerbehebung bei diesen Wake Locks können Sie den Background Task Inspector für die lokale Fehlersuche verwenden oder mit getStopReason Probleme im Feld beheben. 

Android Studio Background Task Inspector

Screenshot des Background Task Inspector, in dem ein Worker mit dem Namen „WeatherSyncWorker“ identifiziert wurde, der häufig wiederholt wurde und fehlgeschlagen ist.

Verwenden Sie dieses Tool auf einem Emulator oder verbundenen Gerät (API-Level 26 oder höher), um WorkManager-Probleme lokal zu debuggen. Es zeigt eine Liste der Worker und ihrer Status (abgeschlossen, wird ausgeführt, in die Warteschlange gestellt) an. So können Sie Details prüfen und Worker-Ketten nachvollziehen. 

So lässt sich beispielsweise erkennen, ob ein Worker häufig fehlschlägt oder Wiederholungsversuche unternimmt, weil er an Systembeschränkungen stößt. 

Weitere Informationen finden Sie in der Dokumentation zum Background Task Inspector.

WorkManager.getStopReason

Für die In-Field-Fehlerbehebung von Workern mit übermäßigen Wake Locks verwenden Sie WorkInfo.getStopReason() in WorkManager 2.9.0 oder höher oder für JobScheduler JobParameters.getStopReason(), das ab SDK 31 verfügbar ist. 

Mit dieser API kann der Grund für das Beenden eines Workers protokolliert werden (z. B. STOP_REASON_TIMEOUT, STOP_REASON_QUOTA). So lassen sich Probleme wie häufige Zeitüberschreitungen aufgrund der erschöpften Laufzeit ermitteln.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

Weitere Informationen finden Sie unter Akkunutzung für APIs zur Aufgabenplanung optimieren.

Andere Arten von übermäßigen Wakelocks debuggen

Bei komplexeren Szenarien mit manuell gehaltenen Wake Locks oder APIs, die den Wake Lock halten, empfehlen wir, System-Traces zu erfassen, um Fehler zu beheben.

System-Trace erfassen

System-Traces  sind ein leistungsstarkes Debugging-Tool, mit dem ein detaillierter Datensatz der Systemaktivität über einen bestimmten Zeitraum erfasst wird. Sie bieten Einblicke in den CPU-Status, die Thread-Aktivität, die Netzwerkaktivität und akkubezogene Messwerte wie die Jobdauer und die Nutzung von Wake Locks.

Sie können einen System-Trace auf verschiedene Arten erfassen: 

• Befehlszeilentool für System-Traces verwenden
• CPU-Profiler von Android Studio verwenden
• Perfetto-UI verwenden
• Aufzeichnen eines Traces manuell auf dem Gerät direkt über die Entwickleroptionen 

Aktivieren Sie in der Perfetto-Benutzeroberfläche auf dem Tab „Android apps & svcs“ die Atrace-Kategorie „power:PowerManagement“. 

Unabhängig von der gewählten Methode ist es wichtig, dass Sie die Atrace-Kategorie „power:PowerManagement“ erfassen, damit Sie die Tracks zum Gerätestatus sehen können. 

Perfetto-UI-Prüfung und SQL-Analyse

System-Traces können in der Perfetto-Benutzeroberfläche geöffnet und untersucht werden. Wenn Sie den Trace öffnen, sehen Sie eine Visualisierung verschiedener Prozesse auf einer Zeitachse. In diesem Leitfaden konzentrieren wir uns auf die Tracks unter „Gerätestatus“.

Pinnen Sie die Tracks unter „Gerätestatus“ an, z. B. „Top-App“, „Bildschirmstatus“, „Lange Wake Locks“ und „Jobs“, um lange Wake-Lock-Abschnitte visuell zu identifizieren.

In jedem Block werden der Name des Ereignisses, der Beginn und das Ende des Ereignisses aufgeführt. In Perfetto wird dies als „Slice“ bezeichnet.

Für die skalierbare Analyse mehrerer Traces können Sie die SQL-Analyse von Perfetto verwenden. Mit einer SQL-Abfrage können alle Wake Locks nach Dauer sortiert werden. So lassen sich die Hauptursachen für eine übermäßige Nutzung ermitteln.

Hier ist ein Beispiel für eine Abfrage, mit der alle Wake-Lock-Tags summiert werden, die im System-Trace aufgetreten sind, sortiert nach Gesamtdauer:

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

ProfilingManager für die Erfassung von In-Field-Traces verwenden

Bei schwer zu reproduzierenden Problemen ist ProfilingManager (in SDK 35 hinzugefügt) eine programmatische API, mit der Entwickler System-Traces im Feld mit Start- und End-Triggern erfassen können. Sie bietet mehr Kontrolle über die Start- und Endauslöserpunkte für die Profilerstellung und erzwingt eine Ratenbegrenzung auf Systemebene, um die Geräteleistung nicht zu beeinträchtigen. 

In der ProfilingManager-Dokumentation finden Sie weitere Informationen zur Implementierung der Erfassung von System-Traces im Feld, einschließlich der programmatischen Erfassung von Traces, der Analyse von Profiling-Daten und der Verwendung von lokalen Debug-Befehlen.

Die mit ProfilingManager erfassten System-Traces ähneln den manuell erfassten Traces. Systemprozesse und andere App-Prozesse werden jedoch aus dem Trace entfernt.

Fazit

Der Messwert „Übermäßige Teil-Wakelocks“ in Android Vitals ist nur ein kleiner Teil unseres fortlaufenden Engagements, Entwickler bei der Reduzierung des Akkuverbrauchs und der Verbesserung der App-Qualität zu unterstützen. 

Wenn Sie Wake Locks verstehen und richtig implementieren, können Sie die Akkunutzung Ihrer App deutlich optimieren. Die Verwendung alternativer APIs, die Einhaltung der Best Practices für Wake Locks und die Nutzung leistungsstarker Debugging-Tools wie Background Task Inspector, System-Traces und ProfilingManager sind entscheidend für den Erfolg Ihrer App bei Google Play.