* changes:
Add GroupCoalescer to new pipeline
Remove onBeginDispatchToListeners from CollectionReadyForBuildListener
Rename NotifServiceListener -> NotificationHandler
Extract NoManSimulator to top level
Since we now perform setWindowingMode for PIP (even for the case of
re-parenting, we move the activities to a new stack first and then set
its windowing mode to PINNED), we can now add this condition.
Bug: 114842032
Bug: 144508210
Test: Try to do repro steps on b/144508210, no longer happens.
Change-Id: I0e491c52273e9d5edef05b1745c5fbffd9361ac0
Adds the GroupCoalescer, which attempts to make posting notification
groups an atomic action. Currently, notif groups are posted in pieces,
with one post per child or summary. As a result, downstream code can't
tell whether a group is currently complete or whether more stuff is
coming down the line. This complicates a lot of logic, especially to do
with heads-upping.
The GroupCoalescer sits between the NotificationListener and the
NotifCollection and controls the flow of notification events between the
two. As a result, the full pipeline is now:
NotificationListener -> GroupCoalescer -> NotifCollection ->
NotifListBuilderImpl
Most events pass through the GroupCoalescer unhindered, but any event
that involves posting a grouped notification is temporarily delayed
within the coalescer to see if any other similar events occur. When the
delay times out, all delayed events for that group are posted to the
NotifCollection in a batch.
It's dangerous to reorder or delay events from the NotificationListener
for too long, so any event that would further modify the group, such as
updating or removing one of the delayed notifications, causes the batch
to be immediately emitted, followed by the modifying event.
Test: atest SystemUITests
Change-Id: I4b5dd1a6acb3a7704b2e199a5ed42fe855ab74cb
I honestly can't remember why we needed this in the first place. But it
also conflicts with a few upcoming concepts:
- Notification batching (we might get multiple dispatchToListeners calls
before we get a single onBuildList call)
- Update debouncing (same issue)
So we're just going to remove it until we come up with a reason to want
it.
Test: atest SystemUITests
Change-Id: I47cb9c8b037af9daba64e1f59b20beddf138cce4
So it can be used by other tests (see following CLs)
Also adds some more methods to SbnBuilder to modify the underling
Notification.
Test: atest
Change-Id: I44c0b13ceabd30d633848a68074c2a9b31427d56
This reduces the overhead of collecting noted app-ops to the same amount
of binder calls as if we would not have the feature
Before (conceptionally):
---------------------------------
mode = service.noteOp()
if (mode == allowed && shouldCollectAsyncOp) {
fixup(message)
service.noteAsyncOp()
}
----------------------------------
After (conceptionally):
----------------------------------
if (shouldCollectAsyncOp) {
fixup(message)
}
mode = service.noteOp(shouldCollectAsyncOp, message)
----------------------------------
Bug: 136505050
Test: atest CtsAppOpsTestCases
Change-Id: If1b535a7c4b0f431f251c5d06cdf496c34920e23
Fix typo: Classifer -> Classifier.
Use Executor instead of Handler in falsing related code.
Show a dump of BrightLingFalsing related information.
Bug: 139785197
Test: atest SystemUITests && manual.
Change-Id: I3be68cb9f27ccfb5a686947cc85aae74f21f099c
am skip reason: Change-Id I2d6ad7621560ef73b10d6eb861c44700b27a2ea6 with SHA-1 809d36111f is in history
Change-Id: I9b6ee11e403d062b50ea9001c9e93bae886b380f
To have consistent code style and avoid format-related comments in code
review, enable clang-format in frameworks/base/core/jni.
Bug: none
Test: repo upload
Change-Id: Ie9e5408d85036dfabae3a9c60b238b4a190da5fc
