Von anderen APIs erstellte Wakelocks identifizieren

Mehrere Bibliotheken und System-APIs können Wake Locks abrufen, die Ihrer App zugeordnet werden. Dadurch kann es schwierig sein, ein Wake Lock in Ihrer App zu identifizieren, das möglicherweise ein Problem verursacht. Wenn Sie eine API missbrauchen, kann es sein, dass Ihre App einen Wake Lock zu lange hält, obwohl Sie die Wake Lock-APIs nicht direkt aufrufen.

In Szenarien, in denen ein Wake Lock von anderen APIs abgerufen wird, sollten Sie den manuellen Abruf von Wake Locks vermeiden.

In diesem Dokument sind einige gängige Namen für Wake Locks aufgeführt, die bei der Verwendung der Wake Lock-Debugging-Tools angezeigt werden können. Möglicherweise werden diese Namen auch in einem Bericht von Vitals angezeigt. In einigen Fällen wurde das Wake Lock möglicherweise von einer Bibliothek oder System-API erstellt. In anderen Fällen gibt es einen Grund dafür, dass das Tool den Namen des Wake Locks, den Sie in der App verwenden, verschleiert. Sie können die Debugging-Tools verwenden, um fehlerhafte Wake Locks zu identifizieren, und dann in diesem Dokument nach dem Namen des Wake Locks suchen, um herauszufinden, welche API das Problem verursacht und wie es behoben werden kann.

In diesem Dokument werden die Szenarien beschrieben, in denen Wake Locks erstellt werden können. In jedem Fall wird die Sperre der App zugeordnet, die diese API aufgerufen hat, auch wenn sie möglicherweise von einer anderen Bibliothek oder API erstellt wurde.

AlarmManager

AlarmManager ruft Wake Locks ab und weist sie der aufrufenden App zu. AlarmManager ruft den Wake Lock ab, wenn der Wecker ausgelöst wird, und gibt ihn frei, wenn die Ausführung der Methode onReceive() des Wecker-Broadcasts abgeschlossen ist.

Wakelock-Namen

AlarmManager erstellt Wake Locks mit dem Namen *alarm*. Die Sternchen sind Teil des Wake Lock-Namens und stellen keine Platzhalter dar.

Empfehlung

Wir empfehlen die folgenden Vorgehensweisen, um das Verhalten von Benachrichtigungen zu optimieren:

  • Verwenden Sie AlarmManager, um die Häufigkeit der Alarmplanung zu optimieren.
  • Verwenden Sie den Alarmtyp RTC_WAKEUP (der das Gerät aktiviert) nur, wenn es notwendig ist.
  • Verwenden Sie Alarme nur sparsam und vermeiden Sie es, in der Methode onReceive() lange Vorgänge auszuführen.

Audio und Medien

Media-APIs können Wake Locks abrufen, wenn Audio aufgenommen oder wiedergegeben wird. Die Wake Locks werden der Anruf-App zugeordnet.

Wakelock-Namen

Media APIs erhalten Wakelocks mit verschiedenen Namen, die mit Audio beginnen:

  • AudioBitPerfect: Wird für die verlustfreie USB-Audiowiedergabe verwendet.
  • AudioDirectOut: Wird für die verlustfreie Audiowiedergabe auf einem Fernseher oder einem speziellen Gerät verwendet.
  • AudioDup: Wird für die Wiedergabe von Benachrichtigungen verwendet, wenn eine Verbindung über Bluetooth oder USB besteht.
  • AudioIn: Wird für die Audioaufnahme im Camcorder-Modus verwendet, wenn das Mikrofon aktiv ist.
  • AudioMix: Wird für die Audiowiedergabe auf einem gemeinsamen Gerät verwendet.
  • AudioOffload: Wird für die langfristige reine Musikwiedergabe in Apps verwendet, die diesen Modus unterstützen.
  • AudioSpatial: Wird für die Wiedergabe von Mehrkanal-Audio für Filme oder Musik auf Geräten verwendet, die Raumklang unterstützen.
  • AudioUnknown: Wird verwendet, wenn die anderen Situationen nicht zutreffen.
  • MmapCapture: Wird für die Audioaufnahme mit geringer Latenz verwendet.
  • MmapPlayback: Wird für die Wiedergabe mit geringer Latenz verwendet, z. B. für Spiele oder professionelle Audioanwendungen.

Empfehlung

Wir empfehlen Folgendes:

  • Verwenden Sie keine Wakelock-Namen, die mit Audio beginnen.
  • Wenn Sie die Media APIs verwenden, müssen Sie keine Wake Locks direkt abrufen. Die APIs rufen die erforderlichen Wake Locks für Sie ab.
  • Wenn Sie Media APIs verwenden, beenden Sie die Mediensitzung, wenn Sie sie nicht mehr benötigen.

Bluetooth

Die Bluetooth-APIs der Plattform enthalten keine Wake Locks, die der Anwendung während Bluetooth-Aktionen zugewiesen werden. Um zu prüfen, ob der Bluetooth-Transport im Hintergrund erfolgt, planen Sie eine Aufgabe mit WorkManager.

Empfehlung

  • Verwenden Sie Companion Device Pairing (Kopplung mit Begleitgerät), 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 zur Kommunikation im Hintergrund erfahren Sie, wie die Bluetooth-Kommunikation im Hintergrund funktioniert.
  • Wenn ein manuelles Wake Lock erforderlich ist, halten Sie es nur für die Dauer der Bluetooth-Aktion.

Gerätesensoren

Es gibt verschiedene Methoden, um Gerätesensordaten wie Schrittzahl, Beschleunigungsmesser- oder Gyroskopdaten zu erfassen.

Verwende unter Wear OS Wear Health Services, um Gerätedaten wie Höhe, Herzfrequenz und zurückgelegte Distanz abzurufen.

Wenn die Daten von anderen Anwendungen erhoben werden, können Sie Health Connect in Kombination mit WorkManager verwenden, um die Daten abzurufen.

Für Szenarien wie das Erfassen der Differenz von Schritten oder der zurückgelegten Distanz können Sie die Recording API auf Mobilgeräten in Kombination mit WorkManager verwenden, um die Daten abzurufen.

In bestimmten Situationen ist möglicherweise eine benutzerdefinierte Erfassung von Gerätesensoren mit SensorManager erforderlich. SensorManager ruft keine Wake Locks im Namen der App ab, es sei denn, der Sensor ist ein Wake-up-Sensor, der mit der isWakeUpSensor API identifiziert werden kann.

Empfehlung

Die Verwendung von Sensoren zur Aufzeichnung mit hohen Samplingraten kann den Akku erheblich entladen. Hier sind Empfehlungen zur Reduzierung des Akkuverbrauchs und der Wake Locks:

  • Wenn du Schritte oder zurückgelegte Distanzen erfassen möchtest, verwende die Recording API, um Daten akkusparend aufzuzeichnen.
  • Verwenden Sie für die passive Sensornachverfolgung unter Wear OS die Wear Health Services, um den Akkuverbrauch zu optimieren.
  • Reduzieren Sie die Sensorfrequenz auf unter 200 Hz.
  • Wenn Sie einen Sensor bei SensorManager registrieren, definieren Sie ein maxReportLatencyUs von mehr als 30 Sekunden, um die Sensor-Batching-Logik zu verwenden und die Anzahl der Unterbrechungen zu reduzieren, die die Anwendung empfängt.
  • Vermeiden Sie es, während der gesamten Dauer der Sensordatenaufzeichnung einen langen Wake Lock zu halten. Planen Sie stattdessen Alarme mit AlarmManager, um alle 30 Sekunden oder länger Sensordaten abzurufen.

Firebase Cloud Messaging (FCM)

Ein Wake Lock wird abgerufen, während eine Firebase Cloud Message (FCM) an die App gesendet wird. Das Wake Lock wird freigegeben, sobald die Ausführung der onMessageReceived()-Methode für die FCM-Übertragung abgeschlossen ist.

Wakelock-Namen

Ein Wake Lock wird mit dem Namen GOOGLE_C2DM abgerufen.

Empfehlung

Wir empfehlen die folgenden Vorgehensweisen, um das Verhalten von FCM zu optimieren:

  • Häufigkeit der FCM-Zustellung optimieren
  • Verwenden Sie FCM mit hoher Priorität nur, wenn die Nachricht tatsächlich sofort zugestellt werden muss.
  • Lassen Sie die onMessageReceived()-Methode so schnell wie möglich durchführen. Weitere Informationen finden Sie in den Firebase-Richtlinien.

JobScheduler

JobScheduler-Jobs erhalten Wakelocks, während Aufgaben im Hintergrund ausgeführt werden. Die Wake Locks werden der App zugeordnet, die die Worker erstellt hat.

Wakelock-Namen

Die von JobScheduler abgerufenen Wake-Lock-Namen hängen von der Android-Systemversion ab, auf der sie ausgeführt werden, und vom Zweck des Jobs.

Die Elemente in spitzen Klammern sind Variablen. Beispiel: „<package_name>“ ist der Name des App-Pakets und nicht der Literaltext <package name>. *job* ist jedoch die Zeichenfolge *job* mit Sternchen. Die Sternchen werden nicht als Platzhalter verwendet.

Android 15 und niedriger

Bei vom Nutzer initiierten Jobs werden Wake Locks mit Namen erstellt, die diesem Muster entsprechen:

*job*u/@<name_space>@/<package_name>/<classname>

Dieses Muster wird auch in anderen Jobs verwendet:

*job*/@<name_space>@/<package_name>/<classname>
Android 16 und höher

Bei vom Nutzer initiierten Jobs werden Wake Locks mit Namen erstellt, die diesem Muster folgen:

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Bei Express-Jobs wird dieses Muster verwendet:

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Bei regulären Jobs wird dieses Muster verwendet:

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
Beispiel

Angenommen, es gibt einen beschleunigten Job mit dem Namespace backup und dem Trace-Tag started. Der Paketname ist com.example.app und die Klasse, die den Job erstellt hat, ist com.backup.BackupFileService.

Auf Geräten mit Android 15 oder niedriger hat der Wake Lock folgenden Namen:

*job*/@backup@/com.example.app/com.backup.BackupFileService

Auf Geräten mit Android 16 oder höher würde das Wake Lock so benannt:

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

Empfehlung

Prüfen Sie Ihre Nutzung von JobScheduler-Aufgaben. Beachten Sie insbesondere unsere Richtlinien zur Optimierung der Akkunutzung für APIs zur Aufgabenplanung.

Standort

LocationManager und FusedLocationProviderClient verwenden Wake Locks, um den Gerätestandort zu ermitteln und bereitzustellen. Die Wake Locks werden der App zugeordnet, die diese APIs aufgerufen hat.

Wakelock-Namen

Standortdienste verwenden die folgenden Namen:

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

Empfehlung

  • Standortnutzung optimieren Sie können beispielsweise Zeitüberschreitungen festlegen, Standortanfragen in Batches zusammenfassen oder passive Standortaktualisierungen verwenden.
  • Wenn Sie die Standort-APIs verwenden, sollten Sie keine Wake Locks direkt abrufen müssen. Die APIs rufen die erforderlichen Wake Locks für Sie ab.

WorkManager

WorkManager-Worker rufen Wakelocks ab, während sie Aufgaben im Hintergrund ausführen. Die Wake Locks werden der App zugeordnet, die die Worker erstellt hat.

Wakelock-Namen

Die von WorkManager abgerufenen Wake-Lock-Namen hängen davon ab, auf welcher Version des Android-Systems sie ausgeführt werden.

Android 15 und niedriger

WorkManager-Aufgaben erstellen Wake Locks mit Namen, die diesem Muster folgen:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 und höher

Für beschleunigte Aufgaben werden Wake Locks mit Namen erstellt, die diesem Muster folgen:

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

Regelmäßige Aufgaben folgen diesem Muster:

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

Standardmäßig ist <trace_tag> der Name des Workers.

Beispiel

Angenommen, es gibt einen beschleunigten Worker namens BackupFileWorker. Der Paketname lautet com.example.app.

Auf Geräten mit Android 15 oder niedriger hat der Wake Lock folgenden Namen:

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Auf Geräten mit Android 16 oder höher und WorkManager 2.10.0+ würde das Wake Lock so benannt:

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Empfehlung

_UNKNOWN

Wenn die Debugging-Tools der Meinung sind, dass ein Wake Lock-Name personenidentifizierbare Informationen enthält, wird der tatsächliche Wake Lock-Name nicht angezeigt. Stattdessen wird das Wake Lock als _UNKNOWN gekennzeichnet. Das kann beispielsweise passieren, wenn der Wake Lock-Name eine E-Mail-Adresse enthält.

Empfehlung

Befolgen Sie die Best Practices für die Benennung von Wakelocks und vermeiden Sie die Verwendung von personenidentifizierbaren Informationen im Wakelock-Namen. Wenn Sie einen Wake Lock mit dem Namen _UNKNOWN finden, der Ihrer App zugeordnet ist, versuchen Sie, ihn zu identifizieren und ihm einen anderen Namen zu geben.