diff options
| author | Ned Burns <pixel@google.com> | 2019-12-12 13:39:20 -0500 |
|---|---|---|
| committer | Ned Burns <pixel@google.com> | 2019-12-12 13:39:20 -0500 |
| commit | c277a31956baf990fcd4b2c0568b6dee3d68665c (patch) | |
| tree | d0f4a75ef40093c6ad656ff9b97ae98e5fed9d5b /rs/java/android/renderscript/ProgramFragmentFixedFunction.java | |
| parent | 0001dbbc0eb328c1c5f1390ea5e0a6b6acc1e3e8 (diff) | |
Fix race condition in NotificationListener
When our NotificationListener first connects to noman, it queries the
list of current notifications and then posts all of them to the
NEM/NotifCollection. However, this is a two-stage process: first it
queries the list of notifications and then it queries the current
ranking map (technically it's actually the reverse because the map is
cached, but the same principle still applies). Between these two calls,
it's possible for notifs to get added or removed.
As a result, it's possible for the ranking map that we receive to be
missing entries for some of the currently-active notifications. This
causes the NEM/NotifCollection to crash downstream since ranking objects
are required for all new notifs. To band-aid over this issue until noman
can give us an atomic query for both values, we just fill in the ranking
map with missing entries.
Fixes: 145236001
Test: atest SystemUITests:NotifCollectionTest
Test: manual
Change-Id: Id9a2df79e7c782c3e090c53f838d5869852e32d9
Diffstat (limited to 'rs/java/android/renderscript/ProgramFragmentFixedFunction.java')
0 files changed, 0 insertions, 0 deletions