| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dependency.get() automatically registers its managed objects to the
DumpManager if they implement Dumpable. However, if code is refactored
that removes all usages of Dependency.get() in favor of Dagger
injection, then there is no longer a guarantee that the class in
question will be registered to DumpManager (and so included in bug
reports).
Instead, remove the auto-registration feature of Dependency in favor of
manually registering all dumpables with the DumpManager.
Bug: 198713580
Test: atest
Change-Id: Ie02a44fb7da0b76bf53da874cc9eee030a1b9173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is far easier to move _everything_ into SysUIComponent, and then
selectively promote things back to GlobalScope and/or WMScope than
it is to try to do it one at a time. With this change, though lots
of files are touched, very little actually changes structurally.
After this change goes in, folks should stop using @Singleton quite
so freely. Most things should live in @SysuiSingleton. @Singleton
is due to quickly be replaced by @GlobalScope.
Bug: 162923491
Test: atest SystemUITests && manual
Change-Id: Idc31d3d83b030581fb1fa869f7fafc4f2d3a8828
|
| |
|
|
|
|
| |
Test: atest
Bug: 163076432
Change-Id: I5b7514f765811ffd3b0aca63d0108591755974ab
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were only updating appOps for notifications with standard
layouts that were associated with a foreground services. However,
non-foreground service notifications can be tagged with appOps, so we
make sure to update these notifications' appOps whenever appOps are
changed. (We do this by tracking all notifications with standard
layouts instead of just the foreground service notifications)
Test: atest AppOpsCoordinatorTest ForegroundServiceControllerTest
Test: manual (use camera on whatsApp, receive message with app op, quit
app, see that app op is gone on the notification)
Fixes: 158585352
Change-Id: I674fc42441c2847a030df03516484ee6cd9217ac
Change-Id: I0527b8596277e53bea5a68aa57e0726aea9d14ac
|
| |
|
|
|
|
|
|
|
|
|
|
| |
@MainHandler, @MainLooper, @MainResources -> @Main
@BgHandler, @BgLooper -> @Background.
Also, move the providers for Handlers and Loopers into the
ConcurrencyModule.
Bug: 146510722
Test: atest SystemUITests
Change-Id: I991735e1fdca397784427409a2ae696a7374f584
|
| |
|
|
|
|
|
|
|
|
|
| |
When strong auth changes, the lockdown mode could change which
changes whether we show certain notifications so we must invalidate
the KeyguardCoordinator's NotifFilter to prevent b/78020486.
Test: manual
Bug: 145659174
Bug: 145134683
Change-Id: I5e7ad481fad1323943ac7bfe6d858efd0b8a0b32
|
| |
|
|
|
|
| |
Test: atest SystemUiTests
Bug: 145134683
Change-Id: Ibd6331c261f96c9ce5ab6c9c453473a7a349c8e8
|
| |
|
|
|
|
| |
Test: atest ForegroundServiceControllerTest
Fixes: 144170894
Change-Id: If9ae7dc81e1b853b2904821baf23eaf55b289fc6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ye olde NotificationData class was responsible for a few general things:
- Keep a list of visible `NotificationEntry`s
- Filter / sort the visible entries
- Keep a sorted / filtered list of those entries
- Answer lots of questions about the entries themselves (rank,
isAmbient, list of entries for current user, etc.)
- Keep track of the current RankingMap
- Set priority buckets on entries
- Tell the group manager when things changed
The basic idea here is to remove NotificationData in favor of 3 other
changes:
1. Any place which needed to query NotificationData for info about the
entry (in particular its ranking) can just ask the entry for it now.
Entries all keep a reference to their rank
2. NotificationEntryManager now just maintains its own list of visible
notifications. It was already the point of contact to get a handle to
NotificationData so this makes call sites simpler.
3. Create a simpler NotificationRankingManager (maybe delete this
eventually) to encapsulate the sorting logic and hang on to the latest
RankingMap
Test: atest SystemUITests
Change-Id: I14073e103c6d50da37207ca8fd86828da0aaaff9
|
| |
|
|
|
|
|
|
|
| |
Since it can cause an update to notification views
and changes to the views must be done on the main thread
Test: atest ForegroundServiceControllerTest
Fixes: 144170894
Change-Id: I788d9b31c0f1ad8d2e1dd1df5ce743100f3a4a67
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove AppOpsManager + ForegroundServiceController from status bar, instead
register for appOps directly in the ForegroundServiceController
- Remove DozeLog from status bar - it's dumped via DumpController
- Remove ZenController from status bar - only NSSL used it and NSSL can
get it via injection
- Remove NotifLog from StatusBar - move the notifLog for inflation from
NotificationRowBinderImpl to NEM's onAsyncInflationFinished method
Test: atest SystemUiTests
Change-Id: I9fba540c0d8af40b1d1939ff8cb06ee1f5dcc534
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By moving where appOps of notifications gets set
When appOps change:
StatusBar detects appOp change and propogates change to
ForegroundServiceController which stores appOp change
(in case notification hasn't been added yet).
This controller will also update the appOps of the relevant
pending/visible notification
When a notification is added/updated:
ForegroundServiceNotificationListener updates the
relevant notification's appOps
Test: atest NotificationEntryManagerTest NotificationDataTest
Test: atest ForegroundServiceControllerTest
Change-Id: I3af4a2cf599d3eba7a0ba6006b3919730e5e658a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces the ForegroundServiceNotificationListener
component, which contains the logic formerly in
ForegroundServiceController for updating its state in response to
notification events. ForegroundServiceNotificationListener adds a
standard NotificationEntryListener to the NotificationEntryManager,
allowing us to remove the explicit calls from NotificationEntryManager;
splitting this out to its own class prevents us from introducing a
circular dependency since NotificationEntryManager still needs to use
the query methods on ForegroundServiceController.
Test: atest SystemUITests, manual
Change-Id: Iec72aa3a9fd90e3f0079db3b2a3c4f1882e59731
|
| |
|
|
|
|
|
|
|
|
| |
ForegroundServiceControllerImpl was the only implementation of
ForegroundServiceController; this change eliminates the interface so
that the class can be broken up into more granular components in a
future CL to help break circular dependencies. No functional changes.
Test: atest SystemUITests, manual
Change-Id: Iabe8ae1dbc42769d5b3e93ebe2249cdc5c3e4e77
|
| |
|
|
|
|
|
|
| |
With active permission icons
Test: atest SystemUITests
Change-Id: I31828f6239b1253794f9569d29dccdac5c10b0da
Fixes: 75276447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Draw over other apps
- Camera
- Microphone
The icons are not yet clickable, and the system 'drawing over
other apps' notification still appears even when the app's
notification is tagged.
Test: runtest systemui
Bug: 64085448
Change-Id: Ib3b0cdd9adced82f562f256cb81af80dc395440d
|
|
|
If an app with a foreground service has (at least one)
FLAG_FOREGROUND notification shown to the user, we allow
that to satisfy the requirement that the user be informed
about such things. But if the fg notification or its channel
is blocked by the user, we show the NOTE_FOREGROUND_SERVICES
notification (a/k/a Dianne's Dungeon) provided to us by the
activity manager.
Note that if even one of the foreground processes for the
current user is missing its disclosure notification, the
user will see the whole dungeon.
Bug: 36891897
Test: runtest -x frameworks/base/packages/SystemUI/tests/src/com/android/systemui/ForegroundServiceControllerTest.java
Change-Id: I435b7c01e60f99da162c9ea61656e2991d2cb87c
|