打ze模式如何影响注册的侦听器（尤其是传感器侦听器）

Question

How does Doze mode affect registered listeners?

Also I would like to know how it does affect sensor listeners if possible.

My problem is that I have a WatchFaceService with a wake lock permission in the manifest. The watchFace runs the onTimeTick every minute. A lot of times this happens when the device is Dozed. At that moment it registers a listener for HR to collect 10 values. Doze mode kicks in after the listener is registered, according to my observations, but the sensor remains active. For example the HR Sensor stays lit.

Is this normal and why? Here are my observations

---

Listener with a sampling period of 0 microseconds:

sensorManager.registerListener(averagingSensorEventListener, sensor, averageSamplingPeriodUs, averageMaxReportLatencyUs);

---

Logs:

06-12 17:35:00.308 724-724/? D/android.sensor.heart_rate: Starting average calculation
06-12 17:36:01.065 724-724/? D/android.sensor.heart_rate: Event value 75.0 accepted
06-12 17:36:01.166 724-724/? D/android.sensor.heart_rate: Event value 75.0 accepted
06-12 17:36:20.471 724-724/? D/android.sensor.heart_rate: Event value 71.0 accepted
06-12 17:37:01.066 724-724/? D/android.sensor.heart_rate: Event value 72.0 accepted
06-12 17:38:01.067 724-724/? D/android.sensor.heart_rate: Event value 73.0 accepted
06-12 17:39:00.072 724-724/? D/android.sensor.heart_rate: Event value 81.0 accepted
06-12 17:39:28.135 724-724/? D/android.sensor.heart_rate: Event value 81.0 accepted
06-12 17:39:28.276 724-724/? D/android.sensor.heart_rate: Event value 80.0 accepted
06-12 17:39:29.244 724-724/? D/android.sensor.heart_rate: Event value 77.0 accepted
06-12 17:39:30.110 724-724/? D/android.sensor.heart_rate: Event value 75.0 accepted
06-12 17:39:31.172 724-724/? D/android.sensor.heart_rate: Event value 73.0 accepted
06-12 17:39:31.173 724-724/? D/android.sensor.heart_rate: Stopped listening
06-12 17:39:31.180 724-724/? D/android.sensor.heart_rate: Average calculated: 76.0
06-12 17:39:31.180 724-724/? D/android.sensor.heart_rate: Event value 76.0 accepted

It takes more than 4 minutes to complete and in these minutes the HR sensor is active (green light) without firing the onSensorChanged Callback or reporting a value with the listener registered.

---

UPDATE:

For my problems and after the excellent answer from Morales, I solved it via every time I need to register a listener I acquire a wake lock and I release it after the sampling is done. This way the events are consistent to the times I ask and do not keep the sensor active.

Answer 1

Sensors

Documentation says that there are several sensor types , every sensor has a reporting-mode ( continuous , on-change , one-shot and special ) and every sensor is classified by type sensor returned:

• Wake-up sensor : ensure that their data is delivered independently of the state of the SoC.
• Non-wake-up sensor : do not prevent the SoC from going into suspend mode and do not wake the SoC up to report data.

Doze documentation not points any information about particular sensors, except for significant motion sensor that is required to configure doze mode.

To see the individual sensor type descriptions for details on when the events are generated you can check documentation .

Restrictions

There are some restrictions that apply to your app while in Doze mode:

• Network access is suspended.
• The system ignores wake locks .
• Standard AlarmManager alarms (including setExact() and setWindow() ) are deferred to the next maintenance window.
• The system does not perform Wi-Fi scans.
• The system does not allow sync adapters to run.
• The system does not allow JobScheduler to run.

Doze can affect apps differently, depending on the capabilities they offer and the services they use. Many apps function normally across Doze cycles without modification. In some cases, you must optimize the way that your app manages network , alarms , jobs , and syncs . Apps should be able to efficiently manage activities during each maintenance window .

From Optimizing for Doze and App Standby .