diff options
| author | Evan Laird <evanlaird@google.com> | 2019-12-10 17:15:03 -0500 |
|---|---|---|
| committer | android-build-team Robot <android-build-team-robot@google.com> | 2019-12-18 06:23:19 +0000 |
| commit | 87670f362090b4790d85e1347be9849a7461c2a1 (patch) | |
| tree | 5f6d29c2521ad2511fe64da256ee2559ee84523d /tools/aapt2/java/JavaClassGenerator.cpp | |
| parent | aa2ffea8baea65c13ac2b841b3d581f28261dd2b (diff) | |
DO NOT MERGE: Don't let NotificationEntryManager keep around old RankingMaps
When a notification becomes lifetime-extended, NotificationEntryManager
was holding onto the RankingMap that was passed at the time of removal
of _that_ notification, and using it again in the
NotificationSafeToRemoveCallback. The problem here is that when
onSafeToRemove gets called, it was passing that same stale ranking map
to removeNotification, which caused any notification that arrived in the
intervening time to get improperly ranked.
This fixes an issue where any notification that arrives while another is
lifetime-extended can get the wrong ranking applied to it, causing
trouble later in time such as mis-ranking and mis-sorting until the next
update from system server.
Bug: 146046016
Bug: 119041698
Test: atest SystemUITests
Test: manual - Post a FGS notification and immediately cancel, then post
a regular notification and wait for the FGS notification to dismiss.
Note that the regular notification keeps showing in the status bar.
Change-Id: I3df1279f13c424fcedd878bae2095fadc75d61b4
(cherry picked from commit 323ce6205704cc1b3e13b61286069451643392b5)
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator.cpp')
0 files changed, 0 insertions, 0 deletions