Die Akkulaufzeit ist ein entscheidender Faktor für die Nutzerfreundlichkeit. Wakelocks spielen dabei eine wichtige Rolle. Verwenden Sie sie übermäßig? In diesem Blogpost erfahren Sie, was Wakelocks sind, welche Best Practices für ihre Verwendung gelten und wie Sie das Verhalten Ihrer App mit dem Messwert in der Play Console besser nachvollziehen können.

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

In der Play Console wird jetzt der Akkuverbrauch überwacht. Ein wichtiger Leistungsindikator ist dabei die übermäßige Verwendung von Teil-Wakelocks.

Mit dieser Funktion wird die Bedeutung der Akkueffizienz neben den bestehenden Stabilitätsindikatoren für wichtige Messwerte erhöht: übermäßige Abstürze und ANRs (Application Not Responding), die von Nutzern wahrgenommen werden. Wir haben einen Grenzwert für unerwünschtes Verhalten bei übermäßigen Wakelocks definiert. Wenn Ihr Titel diesen Qualitätsgrenzwert ab dem 1. März 2026 nicht erfüllt, wird er möglicherweise nicht mehr auf prominenten Oberflächen wie Empfehlungen angezeigt. In einigen Fällen wird im Store-Eintrag Ihrer App auch 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 von Android Vitals.

Bei Mobilgeräten gilt der Android Vitals-Messwert für Wakelocks, die nicht ausgenommen sind und abgerufen werden, während das Display ausgeschaltet ist und die App im Hintergrund ausgeführt wird oder ein Dienst im Vordergrund ausgeführt wird. In Android Vitals wird die Verwendung von Teil-Wakelocks als übermäßig betrachtet, wenn:

• Wakelocks innerhalb von 24 Stunden mindestens zwei Stunden lang gehalten werden.
• Dies durchschnittlich über 28 Tage hinweg mehr als 5% der Sitzungen Ihrer App betrifft.

Wakelocks, die von Audio, Standort und JobScheduler-APIs erstellt wurden, die vom Nutzer initiiert wurden, sind von der Berechnung der Wakelocks ausgenommen.

Wakelocks

Ein Wakelock ist ein Mechanismus, mit dem eine App die CPU eines Geräts auch dann aktiv halten kann, wenn der Nutzer nicht aktiv mit dem Gerät interagiert. 

Ein Teil-Wakelock hält die CPU aktiv, auch wenn das Display ausgeschaltet ist, und verhindert, dass die CPU in einen energiesparenden „Suspend“-Zustand wechselt. Ein vollständiger Wakelock hält sowohl das Display als auch die CPU aktiv.

Es gibt zwei Methoden, mit denen Teil-Wakelocks abgerufen werden können:

• Die App ruft den Wakelock manuell ab und gibt ihn wieder frei. Dazu werden PowerManager-APIs für einen bestimmten Anwendungsfall verwendet. Oft wird dies in Verbindung mit einem Dienst im Vordergrund abgerufen. Dabei handelt es sich um eine API für den Plattformlebenszyklus, die für Vorgänge verwendet wird, die für den Nutzer wahrnehmbar sind.
• Alternativ wird der Wakelock von einer anderen API abgerufen und der App aufgrund der Verwendung der API zugewiesen. Weitere Informationen finden Sie im Abschnitt zu Best Practices.

Wakelocks sind zwar für Aufgaben wie das Abschließen eines vom Nutzer initiierten Downloads einer großen Datei erforderlich, aber ihre übermäßige oder unsachgemäße Verwendung kann zu einem erheblichen Akkuverbrauch führen. Es gab Fälle, in denen Apps Wakelocks stundenlang gehalten oder nicht ordnungsgemäß freigegeben haben. Das führte zu Beschwerden von Nutzern über einen erheblichen Akkuverbrauch, auch wenn sie nicht mit der App interagiert haben.

Best Practices für die Verwendung von Wakelocks

Bevor wir uns ansehen, wie Sie die übermäßige Verwendung von Wakelocks beheben können, sollten Sie die Best Practices für Wakelocks beachten. 

Beantworten Sie die folgenden vier wichtigen Fragen.

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

Bevor Sie einen manuellen Teil-Wakelock abrufen, folgen Sie diesem Flussdiagramm:

Flussdiagramm zur Entscheidung, wann ein Wakelock manuell abgerufen werden soll

1. Muss das Display eingeschaltet bleiben?
   • Ja: Informationen finden Sie stattdessen in der Dokumentation zu „Display eingeschaltet lassen“.
2. Führt die Anwendung einen Dienst im Vordergrund aus?
   • Nein: Sie müssen keinen Wakelock manuell abrufen.
3. Ist es nachteilig für die Nutzerfreundlichkeit, wenn das Gerät in den Ruhezustand wechselt?
   • Nein: Wenn Sie beispielsweise eine Benachrichtigung aktualisieren, nachdem das Gerät aufgewacht ist, ist kein Wakelock erforderlich.
   • Ja: Wenn es wichtig ist, zu verhindern, dass das Gerät in den Ruhezustand wechselt, z. B. bei der laufenden 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 Wakelocks identifizieren, die von anderen APIs erstellt wurden finden Sie Szenarien, in denen Wakelocks von anderen APIs wie LocationManager erstellt werden.
   • Wenn keine APIs vorhanden sind, fahren Sie mit der letzten Frage fort.
5. Wenn Sie alle Fragen beantwortet haben und keine Alternative gefunden haben, sollten Sie einen Wakelock manuell abrufen.

2. Benennen Sie den Wakelock richtig?

Wenn Sie Wakelocks manuell abrufen, ist die richtige Benennung für die Fehlerbehebung wichtig:

• Geben Sie im Namen keine personenbezogenen Daten wie E‑Mail-Adressen an. Wenn personenbezogene Daten erkannt werden, wird der Wakelock als _UNKNOWN protokolliert, was die Fehlerbehebung 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 den Wakelock-Tags keine Zähler oder eindeutigen IDs hinzu. Dasselbe Tag sollte jedes Mal verwendet werden, wenn der Wakelock ausgeführt wird, damit das System die Nutzung nach Namen zusammenfassen kann. So lassen sich anormale Verhaltensweisen leichter erkennen.

3. Wird der abgerufene Wakelock immer freigegeben?

Wenn Sie einen Wakelock manuell abrufen, muss die Freigabe des Wakelocks immer ausgeführt werden. Wenn ein Wakelock nicht freigegeben wird, kann das zu einem erheblichen Akkuverbrauch führen. 

Wenn beispielsweise während der Ausführung von „processingWork()“ eine nicht abgefangene Ausnahme ausgelöst wird, wird der Aufruf von „release()“ möglicherweise nie ausgeführt. Verwenden Sie stattdessen einen Try/Finally-Block, um sicherzustellen, dass der Wakelock freigegeben wird, auch wenn eine Ausnahme auftritt.

Außerdem können Sie dem Wakelock ein Zeitlimit hinzufügen, damit er 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. Können Sie die Aufwachfrequenz reduzieren?

Bei regelmäßigen Datenanfragen ist es wichtig, die Häufigkeit zu reduzieren, mit der Ihre App das Gerät aufweckt, um den Akkuverbrauch zu optimieren. Hier einige Beispiele für die Reduzierung der Aufwachfrequenz:

• WorkManager: Erhöhen Sie das periodische Intervall in PeriodicWorkRequests.
• SensorManager: Nutzen 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 das Standort-Batching nutzen, indem Sie mit „setMinUpdateIntervalMillis“ ein Mindestaktualisierungsintervall festlegen.

Weitere Informationen finden Sie in der Dokumentation zu den Best Practices für Wakelocks.

Übermäßige Verwendung von Wakelocks beheben

Auch wenn Sie die besten Absichten haben, kann es zu einer übermäßigen Verwendung von Wakelocks kommen. Wenn Ihre App in der Play Console gekennzeichnet ist, gehen Sie so vor, um das Problem zu beheben:

Erste Identifizierung mit der Play Console

Im Android Vitals-Dashboard für übermäßige Teil-Wakelocks finden Sie Aufschlüsselungen der Namen von Wakelocks, die nicht ausgenommen sind und mit Ihrer App verknüpft sind. Außerdem werden die betroffenen Sitzungen und die Dauer angezeigt. Denken Sie daran, in der Dokumentation nachzusehen, ob der Wakelock-Name von der App oder von einer anderen API gehalten wird.

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

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

Wakelocks, die von Workern gehalten werden, können Sie mit diesem Wakelock-Namen identifizieren:

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

Die vollständige Liste der Varianten von Wakelock-Namen, die von Workern gehalten werden, finden Sie in der Dokumentation. Um diese Wakelocks zu beheben, können Sie den Background Task Inspector für die lokale Fehlerbehebung verwenden oder „getStopReason“ nutzen, um Probleme im Feld zu beheben. 

Background Task Inspector in Android Studio

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

Verwenden Sie dieses Tool auf einem Emulator oder einem verbundenen Gerät (API-Level 26 oder höher), um Probleme mit WorkManager lokal zu beheben. 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.

Sie können beispielsweise sehen, ob ein Worker häufig fehlschlägt oder wiederholt wird, weil Systemlimits erreicht wurden. 

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

WorkManager getStopReason

Verwenden Sie für die Fehlerbehebung von Workern mit übermäßigen Wakelocks im Feld WorkInfo.getStopReason() in WorkManager 2.9.0 oder höher oder für JobScheduler JobParameters.getStopReason() in SDK 31 oder höher. 

Mit dieser API können Sie den Grund dafür protokollieren, warum ein Worker beendet wurde (z. B. STOP_REASON_TIMEOUT, STOP_REASON_QUOTA). So lassen sich Probleme wie häufige Zeitüberschreitungen aufgrund der Erschöpfung der Laufzeit beheben.

  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 beheben

Bei komplexeren Szenarien mit manuell gehaltenen Wakelocks oder APIs, die den Wakelock halten, empfehlen wir, die System-Trace-Erfassung zur Fehlerbehebung zu verwenden.

System-Trace-Erfassung

Ein System-Trace  ist ein leistungsstarkes Tool zur Fehlerbehebung, mit dem eine detaillierte Aufzeichnung der Systemaktivität über einen bestimmten Zeitraum erfasst wird. Es bietet Einblicke in den CPU-Status, die Thread-Aktivität, die Netzwerkaktivität und akkubezogene Messwerte wie die Jobdauer und die Verwendung von Wakelocks.

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

• Mit dem Befehlszeilentool für System-Traces
• Mit dem CPU Profiler von Android Studio
• Mit der Perfetto-UI
• Trace direkt auf dem Gerät über die Entwickleroptionen manuell aufzeichnen. 

Aktivieren Sie die Atrace-Kategorie „power:PowerManagement“ in der Perfetto-UI auf dem Tab „Android-Apps und ‑Dienste“. 

Unabhängig von der gewählten Methode müssen Sie die Atrace-Kategorie „power:PowerManagement“ erfassen, um die Tracks für den Gerätestatus ansehen zu können. 

Perfetto-UI-Prüfung und SQL-Analyse

System-Traces können in der Perfetto-UI geöffnet und geprüft werden. Wenn Sie den Trace öffnen, sehen Sie eine Visualisierung verschiedener Prozesse auf einer Zeitachse. Die Tracks, auf die wir uns in diesem Leitfaden konzentrieren, befinden sich 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 sind der Name des Ereignisses, der Beginn und das Ende des Ereignisses aufgeführt. In Perfetto wird dies als Abschnitt bezeichnet.

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

Hier ist eine Beispielabfrage, 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 für die Trace-Erfassung im Feld 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 End-Triggerpunkte für die Profilerstellung und erzwingt eine Ratenbegrenzung auf Systemebene, um Auswirkungen auf die Geräteleistung zu vermeiden. 

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

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

Fazit

Der Messwert für übermäßige Teil-Wakelocks in Android Vitals ist nur ein kleiner Teil unseres kontinuierlichen Engagements, Entwickler dabei zu unterstützen, den Akkuverbrauch zu reduzieren und die App-Qualität zu verbessern. 

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