Akkunutzung deiner App mit dem Wakelock-Messwert von Android Vitals optimieren

Die Akkulaufzeit ist ein wichtiger Aspekt der Nutzerfreundlichkeit und Wake-Locks spielen dabei eine wichtige Rolle. Verwenden Sie sie übermäßig? In diesem Blogpost erfahren Sie, was Wakelocks sind, welche Best Practices es für ihre Verwendung gibt und wie Sie das Verhalten Ihrer App mithilfe des Play Console-Messwerts besser nachvollziehen können.

Übermäßige Teil-Wakelocks in Android Vitals

In der Play Console wird jetzt die Akkuentladung überwacht, wobei der Schwerpunkt auf der übermäßigen Nutzung von Teil-Wakelocks als wichtige Leistungskennzahl liegt.

Mit dieser Funktion wird die Akkueffizienz neben den bestehenden Hauptmesswerten für die Stabilität – übermäßige von Nutzern wahrgenommene Abstürze und ANR – noch wichtiger. Wir haben einen Grenzwert zu unerwünschtem Verhalten für übermäßige Wakelocks definiert. Wenn Ihr Titel ab dem 1. März 2026 diesen Qualitätsgrenzwert nicht erreicht, wird er möglicherweise nicht mehr auf prominenten Oberflächen wie Empfehlungen angezeigt. In einigen Fällen wird im Store-Eintrag der App auch eine Warnung angezeigt, um die Nutzer darauf hinzuweisen, dass die App den Akku möglicherweise übermäßig beansprucht.

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 erworben werden, während das Display ausgeschaltet ist und die App im Hintergrund ausgeführt wird oder einen Dienst im Vordergrund ausführt. Android Vitals betrachtet die Nutzung von Teil-Wakelocks als übermäßig, wenn:

• Wake-Locks werden innerhalb eines Zeitraums von 24 Stunden mindestens zwei Stunden lang gehalten.
• Das Problem betrifft mehr als 5% der Sitzungen Ihrer App, gemittelt über 28 Tage.

Wake-Locks, die von vom Nutzer initiierten APIs für Audio, Standort und JobScheduler erstellt wurden, werden bei der Berechnung der Wake-Locks nicht berücksichtigt.

Informationen zu Wakelocks

Ein Wakelock ist ein Mechanismus, mit dem eine App die CPU eines Geräts auch dann am Laufen halten 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. Dadurch 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 fordert den Wakelock manuell über PowerManager APIs für einen bestimmten Anwendungsfall an und gibt ihn wieder frei. Häufig wird er in Verbindung mit einem Dienst im Vordergrund angefordert – einer Plattform-Lebenszyklus-API, die für vom Nutzer wahrnehmbare Vorgänge vorgesehen ist.
• Alternativ wird die Wakelock von einer anderen API erworben und der App aufgrund der Verwendung der API zugeschrieben. Weitere Informationen dazu finden Sie im Abschnitt „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 erheblichen Akkuentladung führen. Wir haben Fälle gesehen, in denen Apps Wakelocks stundenlang halten oder nicht richtig freigeben. Das führt zu Beschwerden von Nutzern über einen erheblichen Akkuverbrauch, selbst wenn sie nicht mit der App interagieren.

Best Practices für die Verwendung von Wakelocks

Bevor wir uns mit der Fehlerbehebung bei übermäßiger Nutzung von Wakelocks befassen, sollten Sie sich mit den Best Practices für Wakelocks vertraut machen. 

Beantworten Sie die folgenden vier wichtigen Fragen.

1. Hast du alternative Wakelock-Optionen in Betracht gezogen?

Bevor Sie einen manuellen partiellen Wake-Lock erwerben, sollten Sie sich dieses Entscheidungsflussdiagramm ansehen:

Flussdiagramm zur Entscheidung, wann ein Wakelock manuell erworben werden sollte

1. Muss das Display eingeschaltet bleiben?
   • Ja: Weitere Informationen finden Sie in der Dokumentation zu Display eingeschaltet lassen.
2. Wird in der Anwendung ein Dienst im Vordergrund ausgeführt?
   • Nein: Sie müssen keinen Wakelock manuell anfordern.
3. Ist es für die Nutzererfahrung schädlich, wenn das Gerät in den Ruhezustand wechselt?
   • Nein: Für die Aktualisierung einer Benachrichtigung nach dem Aufwachen des Geräts ist beispielsweise kein Wakelock 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, fahre fort.
4. Gibt es bereits eine API, die das Gerät in deinem Namen aktiv hält?
   • In der Dokumentation Von anderen APIs erstellte Wakelocks identifizieren finden Sie Informationen dazu, wie Sie Wakelocks identifizieren, die von anderen APIs wie LocationManager erstellt wurden.
   • Wenn keine APIs vorhanden sind, fahren Sie mit der letzten Frage fort.
5. Wenn Sie alle diese Fragen beantwortet und festgestellt haben, dass es keine Alternative gibt, sollten Sie einen Wakelock manuell anfordern.

2. Benennst du die Wakelock richtig?

Wenn Sie Wake-Locks manuell erwerben, ist die richtige Benennung für die Fehlerbehebung wichtig:

• Geben Sie im Namen keine personenidentifizierbaren Informationen wie E‑Mail-Adressen an. Wenn personenidentifizierbare Informationen erkannt werden, wird der Wakelock als _UNKNOWN protokolliert, was das Debugging erschwert.
• Benennen Sie den Wakelock nicht programmatisch mit Klassen- oder Methodennamen, da diese durch Tools wie Proguard verschleiert werden können. Verwenden Sie stattdessen einen hartcodierten String.
• Fügen Sie Wakelock-Tags keine Zähler oder eindeutigen Kennungen hinzu. Das gleiche Tag sollte jedes Mal verwendet werden, wenn die Wakelock ausgeführt wird, damit das System die Nutzung nach Name zusammenfassen kann. So lässt sich abnormales Verhalten leichter erkennen.

3. Wird der abgerufene Wakelock immer freigegeben?

Wenn du einen Wake-Lock manuell erwirbst, achte darauf, dass die Wake-Lock-Freigabe immer ausgeführt wird. Wenn eine Wakelock nicht freigegeben wird, kann dies zu einer erheblichen Akkuentladung führen. 

Wenn beispielsweise während „processingWork()“ eine nicht abgefangene Ausnahme ausgelöst wird, wird der Aufruf „release()“ möglicherweise nie ausgeführt. Stattdessen können Sie einen try-finally-Block verwenden, um sicherzustellen, dass der Wakelock auch dann freigegeben wird, wenn eine Ausnahme auftritt.

Außerdem können Sie einen Zeitlimit für die Wakelock-Sperre festlegen, damit sie nach einem bestimmten Zeitraum aufgehoben wird und nicht unbegrenzt aktiv bleibt.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Kannst du die Häufigkeit der Aktivierung reduzieren?

Bei regelmäßigen Datenanfragen ist es für die Akkuoptimierung entscheidend, wie oft Ihre App das Gerät aktiviert. Beispiele für die Reduzierung der Aktivierungshäufigkeit:

• WorkManager:Erhöhen Sie das periodische Intervall in PeriodicWorkRequests.
• SensorManager:Nutze die Batchverarbeitung, indem du beim Registrieren des Listeners maxReportLatencyMs angibst.
• Fused Location Provider:
  • Reduzieren Sie die Häufigkeit des Abrufs von Standorten, indem Sie getLastLocation für den letzten 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 Mindestintervall für Aktualisierungen festlegen.

Weitere Informationen findest du in der Dokumentation zu Best Practices für Wakelocks.

Übermäßige Wakelock-Nutzung beheben

Auch bei den besten Absichten kann es zu einer übermäßigen Nutzung von Wakelocks kommen. Wenn Ihre App in der Play Console gekennzeichnet wurde, können Sie sie so debuggen:

Erstmalige Identifizierung mit der Play Console

Im Android Vitals-Dashboard für übermäßige Teil-Wakelocks finden Sie eine Aufschlüsselung der nicht ausgenommenen Wakelock-Namen, die mit Ihrer App verknüpft sind, einschließlich der betroffenen Sitzungen und Dauern. In der Dokumentation finden Sie Informationen dazu, wie Sie feststellen können, ob der Wakelock-Name von der App oder einer anderen API gehalten wird.

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

Debugging übermäßiger Wakelocks, die von Workern/Jobs gehalten werden

Sie können von Workern gehaltene Wakelocks anhand des folgenden Wakelock-Namens identifizieren:

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

Eine vollständige Liste der Varianten von Worker-Wakelock-Namen finden Sie in der Dokumentation. Zum Debuggen dieser Wakelocks können Sie den Background Task Inspector für das lokale Debugging verwenden oder „getStopReason“ nutzen, um Probleme in der Praxis zu beheben. 

Background Task Inspector in Android Studio

Screenshot des Background Task Inspector, in 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 WorkManager-Probleme lokal zu beheben. Es zeigt eine Liste der Worker und ihren Status (beendet, wird ausgeführt, in der Warteschlange) an, sodass Sie Details prüfen und Worker-Ketten nachvollziehen können. 

So kann beispielsweise erkannt werden, ob ein Worker häufig fehlschlägt oder wiederholt wird, weil er an Systemgrenzen stößt. 

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

WorkManager getStopReason

Für das Debugging von Workern mit übermäßigen Wakelocks im Feld können Sie WorkInfo.getStopReason() in WorkManager 2.9.0 oder höher oder für JobScheduler JobParameters.getStopReason() in SDK 31 oder höher verwenden. 

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 einer zu langen Laufzeit leichter erkennen.

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 debuggen

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 erfassen

Ein System-Trace  ist ein leistungsstarkes Debugging-Tool, das einen detaillierten Datensatz der Systemaktivität über einen bestimmten Zeitraum erfasst. Es bietet Einblicke in den CPU-Status, die Thread-Aktivität, die Netzwerkaktivität und akkubezogene Messwerte wie die Jobdauer und die Nutzung von Wakelocks.

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

• Befehlszeilentool für System-Trace verwenden
• CPU-Profiler von Android Studio verwenden
• Perfetto-Benutzeroberfläche verwenden
• Trace manuell auf dem Gerät direkt über die Entwickleroptionen aufzeichnen 

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

Unabhängig von der gewählten Methode ist es wichtig, dass Sie die Atrace-Kategorie „power:PowerManagement“ erfassen, damit die Tracks zum Gerätestatus angezeigt werden können. 

Perfetto-UI-Prüfung und SQL-Analyse

System-Traces können in der Perfetto-Benutzeroberfläche geöffnet und geprüft 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 lang andauernde Wakelock-Slices visuell zu identifizieren.

In jedem Block werden der Name des Ereignisses sowie der Beginn und das Ende des Ereignisses aufgeführt. In Perfetto wird dies als Slice bezeichnet.

Für eine skalierbare Analyse mehrerer Traces können Sie die SQL-Analyse von Perfetto verwenden. Mit einer SQL-Abfrage können alle Wakelocks nach Dauer sortiert werden, um die Top-Beitragenden für eine übermäßige Nutzung zu ermitteln.

Hier ist eine Beispielabfrage, die alle Wakelock-Tags im System-Trace summiert, 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

Für schwer reproduzierbare Probleme 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 Endtriggerpunkte für die Profilerfassung und erzwingt eine Ratenbegrenzung auf Systemebene, um Auswirkungen auf die Geräteleistung zu vermeiden. 

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

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 „Übermäßige Teil-Wakelocks“ in Android Vitals ist nur ein kleiner Teil unseres kontinuierlichen Engagements, Entwickler dabei zu unterstützen, die Akkuentladung 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 von Best Practices für Wakelocks und die Verwendung leistungsstarker Debugging-Tools wie Background Task Inspector, System Traces und ProfilingManager sind entscheidend für den Erfolg Ihrer App bei Google Play.