Modify start/stop condition for mScreenDozeTimer.

Both Display.STATE_DOZE and Display.STATE_DOZE_SUSPEND returns true in
func isScreenDoze(int state),so if state change from STATE_DOZE to
STATE_DOZE_SUSPEND or the other way round, mScreenDozeTimer.startRunningLocked
may execute many times, then StopwatchTimer.mNesting++ executes
many times, mScreenDozeTimer.stopRunningLocked runs less than
 mScreenDozeTimer.startRunningLocked. The bad result is even we
close ambient.display or stopRunningLocked, the return value from
StopwatchTimer.computeRunTimeLocked() always rises, then Estimated power
for ambient.display in batterystats always rises, it's obviously wrong.
After modifying, startRunningLocked and stopRunningLocked could be
one-to-one correspondence, and the return value from
StopwatchTimer.computeRunTimeLocked() is right.

Problem background: When we turn on AOD(Alway On Display), the display state
may change from STATE_DOZE to STATE_DOZE_SUSPEND or the other way round, then
we find that in BatteryStatsHelper.addAmbientDisplayUsage(), ambientDisplayMs
always rises even after we turn off AOD. ambientDisplayMs equals
mScreenDozeTimer.getTotalLocked(elapsedRealtimeUs, which). At last, we find
that because of the mismatching startRunningLocked and stopRunningLocked,
mNesting is greater than zero even we turn off AOD, then the return value
from computeRunTimeLocked(long curBatteryRealtime) always rises. The appearance
is the ambient.display value in BatteryStats always rises even we turn off AOD.

Test: manual- use modifying version for daily use two days,
the Estimated power for ambient.display is right now.

Change-Id: I7731a60c3bc8be331eebfcd923bb70ecbc661a77
Signed-off-by: zhuguangqing <zhuguangqing@xiaomi.com>

0 files changed, 0 insertions, 0 deletions