Die Akkulaufzeit ist ein entscheidender Aspekt der Nutzererfahrung und 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, wobei der Fokus auf der übermäßigen Verwendung von Teil-Wakelocks als wichtiger Leistungsmesswert liegt.

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 aus Nutzersicht. 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 für die Suche wie Empfehlungen ausgeschlossen. In einigen Fällen wird in Ihrem Store-Eintrag möglicherweise eine Warnung angezeigt, um Nutzer darauf hinzuweisen, dass Ihre App zu einer schnellen Akkuentladung führen kann.

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 durchschnittlich über 28 Tage 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 ausführen kann, wenn der Nutzer nicht aktiv mit dem Gerät interagiert. 

Ein Teil-Wakelock sorgt dafür, dass die CPU auch dann ausgeführt wird, wenn das Display ausgeschaltet ist, und verhindert, dass die CPU in einen energiesparenden „Suspend“-Zustand wechselt. Ein vollständiger Wakelock sorgt dafür, dass sowohl das Display als auch die CPU ausgeführt werden.

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

• Die App ruft den Wakelock manuell ab und gibt ihn wieder frei. Dazu werden PowerManager-APIs für einen bestimmten Anwendungsfall verwendet. Oft wird er in Verbindung mit einem Dienst im Vordergrund abgerufen – einer API für den Plattformlebenszyklus, die für den für den Nutzer wahrnehmbaren Betrieb vorgesehen ist.
• 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 einer schnellen Akkuentladung führen. Wir haben Fälle gesehen, 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 Optionen für Wakelocks in Betracht gezogen?

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

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 Nutzererfahrung, 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 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 diese Fragen beantwortet haben und keine Alternative gefunden haben, sollten Sie einen Wakelock manuell abrufen.

2. Benennen Sie den Wakelock richtig?

Beim manuellen Abrufen von Wakelocks 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 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 anomale 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 einer schnellen Akkuentladung führen. 

Wenn beispielsweise während der Verarbeitung von „processingWork()“ 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 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 die Akku-Optimierung zu unterstützen. 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 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

Das Dashboard für übermäßige Teil-Wakelocks in Android Vitals enthält 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 der Wakelock-Name von der App gehalten wird oder von einer anderen API.

Das Dashboard für übermäßige Teil-Wakelocks in Android Vitals 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 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, sodass Sie Details prüfen und Worker-Ketten nachvollziehen können. 

So lässt sich 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öpften Laufzeitdauer 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 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 manuell auf dem Gerät direkt über die Entwickleroptionen aufzeichnen. 

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

Unabhängig von der gewählten Methode müssen Sie die Atrace-Kategorie „power:PowerManagement“ erfassen, um die Tracks für den Gerätestatus anzeigen 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 dieser Anleitung konzentrieren, befinden sich unter „Device State“.

Pinnen Sie die Tracks unter „Device State“ an, z. B. „Top app“, „Screen state“, „Long Wake locks“ und „Jobs“, um lange Wakelock-Abschnitte visuell zu identifizieren.

In jedem Block sind der Name des Ereignisses, der Startzeitpunkt und der Endzeitpunkt 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 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, 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.