TelephonyScanManager may sometimes encounter a race condition where
Telephony sends it the first scan result before it has saved the
returned scan ID. This causes a crash in the app that's requesting the
scan.
To fix this, synchronize on mScanInfo while requesting the network scan
so that the handler in TelephonyScanManager will wait for the scan ID to
be saved before processing the first message from Telephony.
Bug: 142068098
Test: manual
Change-Id: I0b2b4c6dc749e21641843818293941704ed870a6
am: 67e7268757 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 5136eefeb3 is in history
Change-Id: If638f3a41362dbbc07b101df3ddd9d51c2dfb103
am: 9ec959b8f3 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 09843a687b is in history
Change-Id: I8cb6a74fb003c359cf81f5dbf84d77f675dd5b5c
am: d3618f8275 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 5136eefeb3 is in history
Change-Id: I84e294f2e9e192cfaf1c62cab4b05a1e8b5df7db
am: 3b8c4743f6 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 5136eefeb3 is in history
Change-Id: I5ad32c66fa4502e232b802241789977252ddec8e
It's possible for a service to do a start/stop foreground and cause a
couple of things to happen:
NotificationManagerService will enqueue a EnqueueNotificationRunnable,
post a PostNotificationRunnable (for the startForeground), and then also
enqueue a CancelNotificationRunnable. There is some racy behavior here
in that the cancel runnable can get triggered in between enqueue and
post runnables. If the cancel happens first, then
NotificationListenerServices will never get the message.
This behavior is technically allowed, however for foreground services we
want to ensure that there is a minmum amount of time that notification
listeners are aware of the foreground service so that (for instance) the
FGS notification can be shown.
This CL does two things to mitigate this problem:
1. Introduce checking in the CancelNotificationRunnable such that it
will not cancel until after PostNotificationRunnable has finished
executing.
2. Introduce a NotificationLifetimeExtender method that will allow a
lifetime extender to manage the lifetime of a notification that has been
enqueued but not inflated yet.
Bug: 119041698
Test: atest NotificationManagerServiceTest
Test: atest ForegroundServiceNotificationListenerTest
Change-Id: I0680034ed9315aa2c05282524d48faaed066ebd0
Merged-In: I0680034ed9315aa2c05282524d48faaed066ebd0
This reverts commit 078fe45552.
Reason for revert: This change introduced a bug and it completely changed the functionality of WiFi data stall detection, e.g., high Tx link speed can easily trigger data stall. We would like to roll back them to restore the normal functionality of Wifi data stall detection.
Bug: 141995185
Change-Id: I024808b580955545b084112c4b14921f038b595f
Merged-In: I078d28ed81a84e32aaece839a51590364a974481
It's possible for a service to do a start/stop foreground and cause a
couple of things to happen:
NotificationManagerService will enqueue a EnqueueNotificationRunnable,
post a PostNotificationRunnable (for the startForeground), and then also
enqueue a CancelNotificationRunnable. There is some racy behavior here
in that the cancel runnable can get triggered in between enqueue and
post runnables. If the cancel happens first, then
NotificationListenerServices will never get the message.
This behavior is technically allowed, however for foreground services we
want to ensure that there is a minmum amount of time that notification
listeners are aware of the foreground service so that (for instance) the
FGS notification can be shown.
This CL does two things to mitigate this problem:
1. Introduce checking in the CancelNotificationRunnable such that it
will not cancel until after PostNotificationRunnable has finished
executing.
2. Introduce a NotificationLifetimeExtender method that will allow a
lifetime extender to manage the lifetime of a notification that has been
enqueued but not inflated yet.
Bug: 119041698
Test: atest NotificationManagerServiceTest
Test: atest ForegroundServiceLifetimeExtenderTest
Change-Id: I0680034ed9315aa2c05282524d48faaed066ebd0
Merged-In: I0680034ed9315aa2c05282524d48faaed066ebd0
