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 eigenen 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 wie übermäßige Abstürze und ANRs (Application Not Responding) erhöht. Wir haben einen Grenzwert zu unerwünschtem Verhalten bei übermäßigen Wakelocksdefiniert. Wenn Ihr Titel diesen Qualitätsgrenzwert ab dem 1. März 2026 nicht erfüllt, wird er möglicherweise von prominenten Oberflächen wie Empfehlungen ausgeschlossen. In einigen Fällen wird im Store-Eintrag Ihrer App auch eine Warnung angezeigt, um Nutzer darauf hinzuweisen, dass Ihre App möglicherweise zu einer schnellen Akkuentladung führt.

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

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

• Wakelocks innerhalb von 24 Stunden mindestens zwei Stunden lang gehalten werden.
• Dies sich auf mehr als 5% der Sitzungen Ihrer App auswirkt, im Durchschnitt über 28 Tage.

Wakelocks, die von Audio, Standort und JobScheduler-APIs initiiert werden, 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 das Wakelock manuell ab und gibt es wieder frei. Dazu werden PowerManager-APIs für einen bestimmten Anwendungsfall verwendet. Oft wird es in Verbindung mit einem Dienst im Vordergrund abgerufen. Dabei handelt es sich um eine API für den Lebenszyklus der Plattform, 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 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 einer schnellen Akkuentladung führen. Wir haben Fälle beobachtet, in denen Apps Wakelocks stundenlang halten oder sie nicht ordnungsgemäß freigeben. Das führt zu Beschwerden von Nutzern über eine schnelle Akkuentladung, auch wenn sie nicht mit der App interagieren.

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 diese vier wichtigen Fragen.

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

Bevor Sie ein manuelles Teil-Wakelock abrufen, folgen Sie diesem Entscheidungsflussdiagramm:

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. Wird in der Anwendung ein Dienst im Vordergrund ausgeführt?
   • Nein: Sie müssen kein Wakelock manuell abrufen.
3. Ist es nachteilig für die Nutzerfreundlichkeit, wenn das Gerät in den Suspend-Modus wechselt?
   • Nein: Für das Aktualisieren einer Benachrichtigung, nachdem das Gerät aufgeweckt wurde, ist beispielsweise kein Wakelock erforderlich.
   • Ja: Wenn es wichtig ist, zu verhindern, dass das Gerät in den Suspend-Modus 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 in Ihrem Namen 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 ein Wakelock manuell abrufen.

2. Benennen Sie das Wakelock richtig?

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

• Lassen Sie alle personenbezogenen Daten (personenidentifizierbare Informationen) im Namen weg, z. B. E‑Mail-Adressen. Wenn personenbezogene Daten erkannt werden, wird das Wakelock als _UNKNOWN protokolliert, was die Fehlerbehebung erschwert.
• Benennen Sie Ihr 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. Derselbe Tag sollte jedes Mal verwendet werden, wenn das Wakelock ausgeführt wird, damit das System die Nutzung nach Namen zusammenfassen kann. So lassen sich anormale Verhaltensweisen leichter erkennen.

3. Wird das abgerufene Wakelock immer freigegeben?

Wenn Sie ein Wakelock manuell abrufen, muss die Freigabe des Wakelocks immer ausgeführt werden. Wenn ein Wakelock nicht freigegeben wird, kann das zu einer schnellen Akkuentladung führen. 

Wenn beispielsweise während der Verarbeitung von „work()“ eine nicht abgefangene Ausnahme ausgelöst wird, wird der Aufruf von „release()“ möglicherweise nie ausgeführt. Stattdessen können Sie einen Try/Finally-Block verwenden, um sicherzustellen, dass das 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. 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 die Akku-Optimierung zu unterstützen. Hier einige Beispiele, wie Sie die Aufwachfrequenz reduzieren können:

• 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 minimales Aktualisierungsintervall festlegen.

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

Übermäßige Verwendung von Wakelocks beheben

Auch mit den besten Absichten 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 nicht ausgenommenen Wakelock-Namen, die mit Ihrer App verknüpft sind, sowie die betroffenen Sitzungen und Zeiträume. Denken Sie daran, in der Dokumentation nachzusehen, ob das Wakelock 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 von 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 WorkManager-Probleme lokal zu beheben. 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 können Sie beispielsweise feststellen, ob ein Worker häufig fehlschlägt oder wiederholt wird, weil Systembeschränkungen 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 das 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 ein System-Trace auf verschiedene Arten erfassen: 

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

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, damit Sie die Tracks zum Gerätestatus sehen 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 das 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.