summaryrefslogtreecommitdiff
path: root/packages/SystemUI/src/com/android/systemui/ForegroundServiceController.java
Commit message (Collapse)AuthorAgeFilesLines
* Manually register Dumpables to DumpManagerNed Burns2021-09-081-1/+2
| | | | | | | | | | | | | | | | 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
* 6/N Move everything into SysUIComponent.Dave Mankoff2020-08-161-6/+2
| | | | | | | | | | | | | | | 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
* Remove app ops indicators from notificationsJulia Reynolds2020-08-131-47/+3
| | | | | | Test: atest Bug: 163076432 Change-Id: I5b7514f765811ffd3b0aca63d0108591755974ab
* Track non-foreground service notifs for appOpsBeverly2020-06-161-24/+28
| | | | | | | | | | | | | | | | | 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
* Conslidate @MainHandler and similar to @Main (and similar).Dave Mankoff2019-12-201-2/+2
| | | | | | | | | | | | @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
* invalidate NotifFilter onStrongAuthStateChangedBeverly2019-12-051-0/+2
| | | | | | | | | | | 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
* Add Coordinators to replace NotificationFilterBeverly2019-12-041-1/+1
| | | | | | Test: atest SystemUiTests Bug: 145134683 Change-Id: Ibd6331c261f96c9ce5ab6c9c453473a7a349c8e8
* Test that appOps added to notifs from mainThreadBeverly2019-11-191-0/+3
| | | | | | Test: atest ForegroundServiceControllerTest Fixes: 144170894 Change-Id: If9ae7dc81e1b853b2904821baf23eaf55b289fc6
* Remove NotificationDataEvan Laird2019-11-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Call appOps changed from main threadBeverly2019-11-081-5/+13
| | | | | | | | | 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
* Some StatusBar cleanupBeverly2019-11-071-1/+10
| | | | | | | | | | | | | - 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
* Remove onBeforeNotificationAdded callBeverly2019-10-241-6/+39
| | | | | | | | | | | | | | | | | | | 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
* Factors out notification listening from ForegroundServiceController.Gus Prevas2019-01-041-207/+43
| | | | | | | | | | | | | | | 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
* Collapses ForegroundServiceControllerImpl into interface.Gus Prevas2019-01-041-29/+286
| | | | | | | | | | 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
* Only tag foreground notificationsJulia Reynolds2018-04-031-1/+1
| | | | | | | | With active permission icons Test: atest SystemUITests Change-Id: I31828f6239b1253794f9569d29dccdac5c10b0da Fixes: 75276447
* Tag foreground notis that use certain servicesJulia Reynolds2018-02-281-0/+30
| | | | | | | | | | | | | | - 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
* Hide redundant foreground service notifications.Dan Sandler2017-06-061-0/+49
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