Akkunutzung Ihrer App mit dem Android Vitals-Messwert zu 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äßigen Einsatz von Teil-Wakelocks als wichtiger Leistungsindikator besondere Aufmerksamkeit geschenkt.

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 zu unerwünschtem 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 der Android Vitals-Messwert für nicht ausgenommene Wakelocks, die abgerufen werden, wenn der Bildschirm ausgeschaltet ist und die App im Hintergrund ausgeführt wird oder einen Dienst im Vordergrund ausführt. Die Verwendung von Teil-Wakelocks gilt bei Android Vitals als übermäßig, wenn:

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

Von den nutzerinitiierten APIs audio, location und JobScheduler erstellte Wakelocks sind von der Wakelock-Berechnung ausgenommen.

Wakelocks

Ein Wakelock ist ein Mechanismus, mit dem eine App die CPU eines Geräts auch dann weiterlaufen lassen 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 einen 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 Wakelock manuell ab und gibt es wieder frei. Dazu werden PowerManager-APIs für einen bestimmten Anwendungsfall verwendet. Das Wakelock wird häufig in Verbindung mit einem Dienst im Vordergrund abgerufen. Dies ist eine Plattform-Lifecycle-API, die für den für Nutzer wahrnehmbaren Betrieb vorgesehen ist.
• Alternativ wird das Wakelock 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 einer schnellen Akkuentladung führen. Es gibt Fälle, in denen Apps Wakelocks stundenlang halten oder nicht richtig freigeben. Dies führt zu Nutzerbeschwerden über eine schnelle Akkuentladung, 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 Wakelocks debuggen können, sollten Sie die Best Practices für Wakelocks beachten. 

Beantworten Sie diese vier wichtigen Fragen.

1. Haben Sie alternative Wakelock-Optionen in Betracht gezogen?

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

Flussdiagramm zur Entscheidung, wann ein Wakelock manuell abgerufen werden sollte

1. Muss das Display eingeschaltet bleiben?
   • Ja: Sieh dir stattdessen die Dokumentation zu Display anlassen an.
2. Wird in der Anwendung ein Dienst im Vordergrund ausgeführt?
   • Nein: Sie müssen kein Wakelock manuell abrufen.
3. Beeinträchtigt es die Nutzerfreundlichkeit, 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 Ruhemodus wechselt, z. B. bei laufender Kommunikation mit einem externen Gerät, fahren Sie 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 Wakelocks 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 (PII) 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 Wakelock nicht programmatisch mit Klassen- oder Methodennamen, da diese durch Tools wie Proguard verschleiert werden können. Verwenden Sie stattdessen einen fest codierten String.
• Fügen Sie keine Zähler oder eindeutigen Kennungen zu Wakelock-Tags hinzu. Dasselbe Tag sollte jedes Mal verwendet werden, wenn der Wakelock ausgeführt wird, damit das System die Nutzung nach Namen zusammenfassen kann und sich anomales Verhalten leichter erkennen lässt.

3. Wird der erworbene Wakelock immer freigegeben?

Wenn Sie einen Wakelock manuell abrufen, muss die Wakelock-Freigabe immer ausgeführt werden. Wenn Sie ein Wakelock nicht freigeben, kann dies zu einer schnellen Akkuentladung 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 der Wakelock freigegeben wird, auch wenn eine Ausnahme auftritt.

Außerdem können Sie dem Wakelock 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 Akku-Optimierung wichtig, dass Ihre App das Gerät seltener aktiviert. Beispiele für die Reduzierung der Aufwachhäufigkeit:

• WorkManager:Erhöhe das periodische Intervall in PeriodicWorkRequests.
• SensorManager:Verwenden Sie Batching, indem Sie maxReportLatencyMs beim Registrieren des Listeners angeben.
• Anbieter für kombinierte Standortbestimmung
  :
  • Reduzieren Sie die Häufigkeit des Abrufs von Standorten, indem Sie getLastLocation für den zuletzt im Cache gespeicherten Standort verwenden.
  • Verwenden Sie setPriority(PRIORITY_PASSIVE) für eine weniger akkuintensive Aktualisierungsmethode.
  • Sie können auch 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 Wakelocks.

Übermäßige Wakelock-Nutzung debuggen

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

Erste Identifizierung über die Play Console

Das Dashboard „Übermäßige Teil-Wakelocks“ in Android Vitals enthält Aufschlüsselungen der nicht ausgenommenen Wake-Lock-Namen, die mit Ihrer App verknüpft sind. Außerdem werden die betroffenen Sitzungen und Zeiträume angezeigt. Denken Sie daran, dass Sie anhand der Dokumentation herausfinden können, ob der Wakelock-Name von der App oder von einer anderen API verwendet wird.

Das Dashboard „Übermäßige Teil-Wakelocks“ von Android Vitals wurde zum Abschnitt „Aufschlüsselungen“ gescrollt, um Tags für übermäßige Wakelocks aufzurufen.

Übermäßige Wakelocks, die von Workern/Jobs gehalten werden, debuggen

Sie können Worker-Wakelocks anhand dieses Wakelock-Namens identifizieren:

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

Eine vollständige Liste der Varianten von Namen für Worker-Wakelocks ist in der Dokumentation verfügbar. Um diese Wake Locks zu debuggen, können Sie den Background Task Inspector für das lokale Debugging verwenden oder getStopReason nutzen, um Probleme im Feld zu beheben. 

Android Studio Background Task Inspector

Screenshot des Background Task Inspector, in dem ein Worker namens „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

Verwenden Sie für die In-Field-Fehlerbehebung von Workern mit übermäßigen Wake Locks 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 dafür protokolliert werden, warum ein Worker beendet wurde (z. B. STOP_REASON_TIMEOUT, STOP_REASON_QUOTA). So lassen sich Probleme wie häufige Zeitüberschreitungen aufgrund einer zu langen 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 Task Scheduling APIs optimieren.

Andere Arten von übermäßigen Wakelocks debuggen

Bei komplexeren Szenarien mit manuell gehaltenen Wakelocks oder APIs, die den Wakelock halten, empfehlen wir, System-Traces zu verwenden, um Fehler zu beheben.

System-Trace erfassen

System-Traces  sind ein leistungsstarkes Debugging-Tool, mit dem detaillierte Aufzeichnungen der Systemaktivität über einen bestimmten Zeitraum erfasst werden. Sie liefern Informationen zum CPU-Status, zur Thread-Aktivität, zur Netzwerkaktivität und zu akkubezogenen Messwerten wie Jobdauer und Wakelock-Nutzung.

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

• System Trace Command Line Tool verwenden
• CPU Profiler von Android Studio verwenden
• Perfetto-Benutzeroberfläche verwenden
• Eine Aufzeichnung manuell auf dem Gerät direkt über die Entwickleroptionen starten. 

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 Gerätestatus-Tracks 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“ wie „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 Wakelock-Tags summiert werden, die in der Ablaufverfolgung 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 zum Erfassen 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 haben mehr Kontrolle über die Start- und Endauslöserpunkte für die Profilerstellung und es wird eine Ratenbegrenzung auf Systemebene erzwungen, 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 Debugging-Befehlen.

Die mit ProfilingManager erfassten System-Traces ähneln den manuell erfassten, aber Systemprozesse und andere App-Prozesse werden 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 von Best Practices für Wakelocks 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.