This CL adds a safeguard in ShareSheet to avoid calls to
AppPredictionService when the service is defined but is not available,
for example in the case of a wrong AiAi apk pushed from GooglePlay.
Bug: 138595943
Test: Manual test by removing the AiAi package from device
Change-Id: I4109c5122faa753d5111ee45698301cb6ccdd7b5
This combines ag/8888937 and ag/9019277 into one CL, plus fixes another issue
where the timer could restart if the user had removed a notification and then
restarted the stream
Fixes: 138261464
Test: manual, atest NotificationMediaTemplateViewWrapperTest
Also checked the changes on the master branch since that had very
obvious issues when locking / unlocking the phone before
Change-Id: I6a0bbc675d33a5c7d4ce7f0884aec19606bff4fa
hex 'a' is not correctly deserialized in readThisByteArrayXml.
Change readThisByteArrayXml & writeByteArrayXml to use HexEncoding for
hex conversions.
Bug: 138482990
Test: Was seeing parsing errors with ag/9135251.
Validated the fix with ag/9135251.
Change-Id: If9f86b5ed85a9f883130e4110f85cd2faa995439
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>
If /sys/class/wakeup is available, get both kernel and native wakelock
stats from SystemSuspend, else we get native wakelock stats from
SystemSuspend and fallback to /d/wakeup_sources for kernel wakelock
stats.
Bug: 128923994
Test: atest FrameworksCoreTests:KernelWakelockReaderTest
Test: Compare dumpsys suspend_control against
dumpsys batterystats --checkin | grep kwl
to verify BatteryStats is getting wakelock stats
from SystemSuspend.
Change-Id: I08e56c984b903285bb965dd853dae4a63fdeb824
