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. Ein wichtiger Leistungsindikator ist dabei die übermäßige Verwendung von Teil-Wakelocks.

Diese Funktion unterstreicht die Bedeutung der Energieeffizienz 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 einen übermäßigen Akkuverbrauch verursacht.

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 Dienst im Vordergrund 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 Wakelocks sind von der Wakelock-Berechnung ausgenommen.

Wakelocks

Ein Wakelock 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 Wakelock manuell ab und gibt es wieder frei. Dazu werden PowerManager-APIs für einen bestimmten Anwendungsfall verwendet. Häufig wird das Wakelock 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 dazu 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 ist vorgekommen, dass Apps Wakelocks stundenlang gehalten oder nicht richtig freigegeben haben. Das hat zu Nutzerbeschwerden über eine erhebliche schnelle Akkuentladung geführt, auch wenn sie nicht mit der App interagiert haben.

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 soll

1. Muss der Bildschirm eingeschaltet bleiben?
   • Ja: Sehen Sie sich stattdessen die Dokumentation zu Display immer an an.
2. Wird in der Anwendung ein Dienst im Vordergrund ausgeführt?
   • Nein. Sie müssen kein Wakelock 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 Wakelock 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 Wakelocks fortfahren.

2. Geben Sie den Wakelock-Namen richtig an?

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 der Wakelock als _UNKNOWN protokolliert, was das Debugging erschwert.
• Benennen Sie Ihren Wakelock 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 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. So lässt sich anomales Verhalten leichter erkennen.

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 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 entscheidend, wie oft Ihre App das Gerät aktiviert. Beispiele für die Reduzierung der Aktivierungshäufigkeit:

• WorkManager:Erhöhe das periodische Intervall in PeriodicWorkRequests.
• SensorManager:Nutzen Sie die Batchverarbeitung, 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 Standort-Batchverarbeitung 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 beheben

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 partielle Wakelocks“ in Android Vitals enthält Aufschlüsselungen von nicht ausgenommenen Wakelock-Namen, die mit Ihrer App verknüpft sind. Außerdem werden betroffene Sitzungen und Zeiträume angezeigt. Erinnerung, die Dokumentation zu verwenden, um festzustellen, ob der Wakelock-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 von Workern gehaltene Wakelocks anhand dieses Wakelock-Namens identifizieren:

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

Die 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 mit getStopReason Probleme im Feld debuggen. 

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, sodass Sie Details prüfen und Worker-Ketten nachvollziehen können. 

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 das Debugging von Workern mit übermäßigen Wake Locks im Feld 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

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 erfassen, 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: 

• Mit dem Befehlszeilentool für System-Traces
• 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 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“ an, z. B. „Top-App“, „Bildschirmstatus“, „Lange Wakelocks“ und „Jobs“, um lange Wakelock-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 lassen sich alle Wake Locks nach Dauer sortiert finden. So können Sie 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 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 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 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 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.