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 Wake Lock-Behandlungen für technische Qualität begonnen, um den Akkuverbrauch 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 für unerwünschtes Verhalten überschreitet. 

Durch diese Initiative wurde die Akkueffizienz zu einem wichtigen Vitals-Messwert neben Stabilitätsmesswerten wie Abstürzen und ANRs. Der Grenzwert für unerwünschtes 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 Wake Lock ist ausgenommen, wenn es sich um ein vom System gehaltenes Wake Lock 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 oft 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

Wir haben oft gesehen, dass Entwickler Schwierigkeiten haben, den Unterschied zwischen zwei Konzepten bei der Ausführung im Hintergrund zu verstehen: Vordergrunddienst 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 Wake Lock 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 Wake Locks 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 Wake Lock 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 Wake Lock in Szenarien erworben wird, in denen es 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 Wake Lock nicht einfach identifiziert werden kann, reproduzieren Sie das Wake Lock-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 von uns untersuchten Anwendungsfälle sowie den empfohlenen Weg zur Optimierung Ihrer Wake Lock-Implementierung.

Vom Nutzer initiiertes Hoch- oder Herunterladen

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 Wake Lock-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, indem Aufgaben in Batches verarbeitet werden. Außerdem gibt es ein Mindestintervall (15 Minuten), das in der Regel für Hintergrundaktualisierungen ausreicht. 
• Wenn Sie von WorkManager oder JobScheduler erstellte Wake Locks 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 sollten auch System-Traces  erfassen und analysieren, um zu verstehen, 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 Wake Locks 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 von Begleitgeräten, um Bluetooth-Geräte zu koppeln und so zu vermeiden, dass während der Bluetooth-Kopplung ein manuelles Wake Lock erworben wird. 
• In der Anleitung  Im Hintergrund kommunizieren erfährst du, wie du Bluetooth-Kommunikation im Hintergrund durchführst. 
• Die Verwendung von WorkManager ist oft ausreichend, wenn eine verzögerte Kommunikation keine Auswirkungen auf die Nutzer hat. Wenn ein manueller Wake Lock 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, ein separates, kontinuierliches Wake Lock 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 historische 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. Wenn Sie Sensorwerte an den kurzen Wakelock anhängen, den das System für Standortaktualisierungen verwendet, ist kein Wakelock erforderlich, um die CPU aktiv zu halten. Verwende einen Worker oder einen Wake Lock 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 Wake Lock erforderlich, um auf Ereignisunterbrechungen zu warten. Wenn Datenpakete am WLAN- oder Mobilfunkmodul eintreffen, löst die Funkhardware einen Hardware-Interrupt in Form eines Kernel-Wake-Locks aus. Anschließend können Sie einen Worker planen oder ein Wake Lock 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 Wake Lock 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 die Synchronisierung im Hintergrund, die Standortbestimmung, die Sensorüberwachung und die Netzwerkkommunikation verwenden, können sie die unnötige Verwendung von Wake Locks 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.