Da ein übermäßiger Akkuverbrauch für Android-Nutzer ein wichtiges Thema ist, hat Google erhebliche Maßnahmen ergriffen, um Entwicklern dabei zu helfen, energieeffizientere Apps zu entwickeln. Am 1. März 2026 hat der Google Play Store mit der Einführung der Wakelock-Behandlungen für technische Qualität begonnen, um die schnelle Akkuentladung zu verbessern. Diese Maßnahme wird in den kommenden Wochen schrittweise auf betroffene Apps ausgeweitet. Apps, die den Grenzwert für „Übermäßiger partieller Wakelock“ in Android Vitals regelmäßig überschreiten, können sich spürbar auf die App-Präsenz im Play Store auswirken. Dazu gehören Warnungen im Store-Eintrag und der Ausschluss von Plattformen wie Empfehlungen, auf denen Apps präsentiert werden.

Nutzern wird eventuell eine Warnung in Ihrem Store-Eintrag angezeigt, wenn Ihre App den Grenzwert zu unerwünschtem Verhalten überschreitet. 

Durch diese Initiative wurde die Akkueffizienz zu einem wichtigen Vitals-Messwert neben Stabilitätsmesswerten wie Abstürzen und ANRs. Der Grenzwert zu unerwünschtem Verhalten wird definiert als das durchschnittliche Halten eines nicht ausgenommenen partiellen Wakelocks für mindestens zwei Stunden, während der Bildschirm in mehr als 5% der Nutzersitzungen in den letzten 28 Tagen ausgeschaltet ist. Ein Wakelock ist ausgenommen, wenn es sich um ein vom System gehaltenes Wakelock handelt, das klare Vorteile für den Nutzer bietet, die nicht weiter optimiert werden können, z. B. Audiowiedergabe, Standortzugriff oder vom Nutzer initiierte Datenübertragung. Die vollständige Definition von übermäßigen Wakelocks finden Sie in der Android Vitals-Dokumentation.

Im Rahmen unserer laufenden Initiative zur Verbesserung der Akkulaufzeit im gesamten Android-Ökosystem haben wir Tausende von Apps und die Art und Weise, wie sie partielle Wake Locks verwenden, analysiert. Wake Locks sind zwar manchmal erforderlich, aber wir stellen häufig fest, dass Apps sie ineffizient oder unnötig verwenden, obwohl es effizientere Lösungen gibt. In diesem Blogbeitrag werden die häufigsten Szenarien beschrieben, in denen übermäßige Wake Locks auftreten, und unsere Empfehlungen zur Optimierung von Wake Locks.  Partner wie WHOOP haben bereits messbare Erfolge erzielt, indem sie diese Empfehlungen genutzt haben, um das Verhalten ihrer App im Hintergrund zu optimieren.

Dienst im Vordergrund im Vergleich zu partiellen Wake Locks

Oft fällt es Entwicklern schwer, den Unterschied zwischen zwei Konzepten bei der Ausführung im Hintergrund zu verstehen: Dienst im Vordergrund und partielle Wake Locks.

Ein Dienst im Vordergrund ist eine Lifecycle-API, die dem System signalisiert, dass eine App für den Nutzer wahrnehmbare Aufgaben ausführt und nicht beendet werden sollte, um Arbeitsspeicher freizugeben. Sie verhindert jedoch nicht automatisch, dass die CPU in den Ruhezustand wechselt, wenn der Bildschirm ausgeschaltet wird. Im Gegensatz dazu ist ein partielles Wakelock ein Mechanismus, der speziell dafür entwickelt wurde, die CPU auch bei ausgeschaltetem Bildschirm am Laufen zu halten.

Ein Dienst im Vordergrund ist oft erforderlich, um eine Nutzeraktion fortzusetzen. Ein manuelles Abrufen eines partiellen Wakelocks ist jedoch nur in Verbindung mit einem Dienst im Vordergrund für die Dauer der CPU-Aktivität erforderlich. Außerdem müssen Sie keine Wakelock verwenden, wenn Sie bereits eine API nutzen, die das Gerät aktiv hält. 

Sehen Sie sich das Flussdiagramm unter Die richtige API auswählen, um das Gerät aktiv zu halten an, um zu verstehen, welches Tool Sie verwenden sollten, um zu vermeiden, dass ein Wakelock in Szenarien erworben wird, in denen er nicht erforderlich ist.

Wake Locks durch Bibliotheken von Drittanbietern

Es ist üblich, dass eine App feststellt, dass sie aufgrund von übermäßigen Wake Locks, die von einem Drittanbieter-SDK oder einer System-API in ihrem Namen gehalten werden, gekennzeichnet ist. So können Sie diese Wake Locks identifizieren und beheben:

• Android Vitals prüfen:Den genauen Namen des problematischen Wakelocks finden Sie im Dashboard für übermäßige teilweise Wakelocks. Vergleichen Sie diesen Namen mit der Anleitung unter Von anderen APIs erstellte Wake Locks identifizieren, um festzustellen, ob er von einer bekannten System-API oder Jetpack-Bibliothek erstellt wurde. Wenn das der Fall ist, müssen Sie möglicherweise die Nutzung der API optimieren. Die empfohlene Anleitung kann Ihnen dabei helfen.
• System-Trace aufzeichnen:Wenn der Wakelock nicht einfach zu identifizieren ist, reproduzieren Sie das Wakelock-Problem lokal mit einem System-Trace und untersuchen Sie es mit der Perfetto-Benutzeroberfläche. Weitere Informationen dazu finden Sie in diesem Blogpost im Abschnitt Debugging other types of excessive wake locks .
• Alternativen in Betracht ziehen:Wenn eine ineffiziente Drittanbieterbibliothek dafür verantwortlich ist und nicht so konfiguriert werden kann, dass der Akku geschont wird, sollten Sie das Problem den SDK-Inhabern mitteilen, ein alternatives SDK suchen oder die Funktion selbst entwickeln.

Häufige Wakelock-Szenarien

Im Folgenden finden Sie eine Aufschlüsselung einiger der spezifischen Anwendungsfälle, die wir uns angesehen haben, sowie den empfohlenen Weg zur Optimierung Ihrer Wakelock-Implementierung.

Vom Nutzer initiierter Upload oder Download

Beispiele für Anwendungsfälle: 

• Videostreaming-Apps, in denen der Nutzer den Download einer großen Datei für den Offlinezugriff auslöst
• Apps zur Mediensicherung, in denen der Nutzer das Hochladen seiner letzten Fotos über eine Benachrichtigung auslöst.

So reduzieren Sie Wakelocks: 

• Keinen manuellen Wakelock abrufen. Verwenden Sie stattdessen die User-Initiated Data Transfer (UIDT) API. Dies ist der vorgesehene Pfad für vom Nutzer initiierte, lang andauernde Datenübertragungsaufgaben. Er ist von übermäßigen Wakelock-Berechnungen ausgenommen.

Einmalige oder regelmäßige Hintergrundsynchronisierungen

Beispiele für Anwendungsfälle: 

• Eine App führt regelmäßige Hintergrundsynchronisierungen durch, um Daten für den Offlinezugriff abzurufen. 
• Schrittzähler-Apps, die regelmäßig die Schrittzahl abrufen.

So reduzieren Sie Wakelocks: 

• Keinen manuellen Wakelock abrufen. Verwenden Sie WorkManager, der für einmalige oder regelmäßige Aufgaben konfiguriert ist. WorkManager berücksichtigt den Systemstatus durch das Batching von Aufgaben und hat ein minimales periodisches Intervall (15 Minuten), das im Allgemeinen für Hintergrundaktualisierungen ausreicht. 
• Wenn Sie von WorkManager oder JobScheduler erstellte Wakelocks mit hoher Nutzung identifizieren, liegt das möglicherweise daran, dass Sie Ihren Worker so konfiguriert haben, dass er in bestimmten Szenarien nicht abgeschlossen wird. Analysieren Sie die Gründe für das Beenden von Worker-Prozessen, insbesondere wenn STOP_REASON_TIMEOUT häufig auftritt. 

workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

• Zusätzlich zum Protokollieren der Gründe für das Beenden von Workern finden Sie weitere Informationen in unserer Dokumentation zum Debuggen von Workern. Sie können auch System-Traces  erfassen und analysieren, um zu sehen, wann Wake Locks aktiviert und deaktiviert werden.
• In dieser Fallstudie erfahren Sie, wie WHOOP ein Problem mit der Konfiguration seiner Worker erkannt und die Auswirkungen von Wakelocks deutlich reduziert hat.

Bluetooth-Kommunikation

Beispiele für Anwendungsfälle: 

• Die Companion-Geräte-App fordert den Nutzer auf, sein externes Bluetooth-Gerät zu koppeln.
• Die Companion-Geräte-App wartet auf Hardwareereignisse auf einem externen Gerät und auf für den Nutzer sichtbare Änderungen in Benachrichtigungen.
• Der Nutzer der Companion-Geräte-App initiiert eine Dateiübertragung zwischen dem Mobilgerät und dem Bluetooth-Gerät.
• Die Companion-Geräte-App führt gelegentlich Firmware-Updates für ein externes Gerät über Bluetooth durch.

So reduzieren Sie Wakelocks: 

• Verwenden Sie die Kopplung über Begleitgerät, um Bluetooth-Geräte zu koppeln und so zu vermeiden, dass während der Bluetooth-Kopplung ein manuelles Wakelock erworben wird. 
• In der Anleitung  Kommunikation im Hintergrund wird beschrieben, wie die Bluetooth-Kommunikation im Hintergrund funktioniert. 
• Die Verwendung von WorkManager ist oft ausreichend, wenn eine verzögerte Kommunikation keine Auswirkungen auf die Nutzer hat. Wenn ein manueller Wakelock als notwendig erachtet wird, sollte er nur für die Dauer der Bluetooth-Aktivität oder der Verarbeitung der Aktivitätsdaten gehalten werden.

Standortsuche

Beispiele für Anwendungsfälle: 

• Fitness-Apps, die Standortdaten für den späteren Upload zwischenspeichern, z. B. zum Erstellen von Laufrouten
• Apps für Essenslieferdienste, die Standortdaten mit hoher Frequenz abrufen, um den Fortschritt der Lieferung in einer Benachrichtigung oder Widget-Benutzeroberfläche zu aktualisieren.

So reduzieren Sie Wakelocks: 

• Weitere Informationen finden Sie in unserem Leitfaden zur Optimierung der Standortnutzung. Um den Akku zu schonen, sollten Sie Zeitüberschreitungen implementieren, Batching von Standortanfragen nutzen oder passive Standortupdates verwenden.
• Wenn Sie mit den APIs „FusedLocationProvider“ oder „LocationManager“ Standortaktualisierungen anfordern, löst das System während des Standortereignis-Callbacks automatisch ein Aufwachen des Geräts aus. Dieser kurze, vom System verwaltete Wakelock ist von den Berechnungen für übermäßige Teil-Wakelocks ausgenommen.
• Vermeiden Sie es, einen separaten, kontinuierlichen Wakelock für das Zwischenspeichern von Standortdaten zu erwerben, da dies redundant ist. Speichern Sie Standortereignisse stattdessen im Arbeitsspeicher oder im lokalen Speicher und verwenden Sie WorkManager, um sie in regelmäßigen Abständen zu verarbeiten.

override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

Hochfrequenz-Sensormonitoring

Beispiele für Anwendungsfälle: 

• Schrittzähler-Apps, die Schritte oder die zurückgelegte Distanz passiv erfassen. 
• Sicherheits-Apps, die die Gerätesensoren in Echtzeit auf schnelle Änderungen überwachen, um Funktionen wie die Unfallerkennung oder die Sturzerkennung bereitzustellen.

So reduzieren Sie Wakelocks: 

• Wenn Sie SensorManager verwenden, beschränken Sie die Nutzung auf regelmäßige Intervalle und nur dann, wenn der Nutzer den Zugriff über eine UI-Interaktion explizit gewährt hat. Die hochfrequente Sensorüberwachung kann den Akku stark belasten, da viele CPU-Aktivierungen und Verarbeitungsvorgänge stattfinden.
• Wenn Sie Schrittzahlen oder zurückgelegte Distanzen erfassen möchten, sollten Sie anstelle von SensorManager die Recording API verwenden oder Health Connect nutzen, um auf bisherige und aggregierte Schrittzahlen des Geräts zuzugreifen und Daten auf akkusparende Weise zu erfassen.
• Wenn Sie einen Sensor mit SensorManager registrieren, geben Sie einen maxReportLatencyUs-Wert von mindestens 30 Sekunden an, um Sensor-Batching zu nutzen und die Häufigkeit von CPU-Unterbrechungen zu minimieren. Wenn das Gerät anschließend durch einen anderen Trigger wie eine Nutzerinteraktion, einen Standortabruf oder einen geplanten Job aktiviert wird, sendet das System die im Cache gespeicherten Sensordaten sofort.

val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

• Wenn Ihre App sowohl Standort- als auch Sensordaten benötigt, synchronisieren Sie das Abrufen und die Verarbeitung der entsprechenden Ereignisse. Indem Sie Sensorwerte an den kurzen Wakelock anhängen, den das System für Standortaktualisierungen verwendet, vermeiden Sie, dass ein Wakelock erforderlich ist, um die CPU aktiv zu halten. Verwende einen Worker oder einen Wakelock mit kurzer Dauer, um das Hochladen und Verarbeiten dieser kombinierten Daten zu verarbeiten.

Remote-Messaging

Beispiele für Anwendungsfälle: 

• Begleit-Apps für die Video- oder Tonüberwachung, die Ereignisse auf einem externen Gerät überwachen müssen, das über ein lokales Netzwerk verbunden ist.
• Messaging-Apps, die eine Netzwerk-Socket-Verbindung mit der Desktop-Variante aufrechterhalten.

So reduzieren Sie Wakelocks: 

• Wenn die Netzwerkereignisse serverseitig verarbeitet werden können, verwenden Sie FCM, um Informationen auf dem Client zu empfangen. Sie können einen beschleunigten Worker planen, wenn eine zusätzliche Verarbeitung von FCM-Daten erforderlich ist. 
• Wenn Ereignisse clientseitig über eine Socket-Verbindung verarbeitet werden müssen, ist kein Wakelock erforderlich, um auf Ereignisunterbrechungen zu warten. Wenn Datenpakete am WLAN- oder Mobilfunkmodul eintreffen, löst die Funkhardware einen Hardware-Interrupt in Form eines Kernel-Wakelocks aus.Anschließend können Sie einen Worker planen oder ein Wakelock abrufen, um die Daten zu verarbeiten.
• Wenn Sie beispielsweise ktor-network verwenden, um Datenpakete an einem Netzwerk-Socket zu empfangen, sollten Sie nur dann einen Wakelock anfordern, wenn Pakete an den Client gesendet wurden und verarbeitet werden müssen.

val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

Zusammenfassung

Wenn Entwickler diese empfohlenen Lösungen für gängige Anwendungsfälle wie Hintergrundsynchronisierungen, Standortbestimmung, Sensormonitoring und Netzwerkkommunikation verwenden, können sie die unnötige Verwendung von Wakelocks reduzieren. Weitere Informationen finden Sie in unserem anderen technischen Blogpost oder in unserem technischen Video zum Ermitteln und Debuggen von Wakelocks: Optimize your app battery using Android vitals wake lock metric. Sehen Sie sich auch unsere aktualisierte Dokumentation zu Wakelocks an. Wenn Sie uns helfen möchten, unsere technischen Ressourcen weiter zu verbessern, können Sie uns in unserer Umfrage zum Feedback zur Dokumentation zusätzliches Feedback zu unseren Anleitungen geben.