summaryrefslogtreecommitdiff
path: root/packages/SystemUI/src/com/android/systemui/statusbar/NotificationRemoteInputManager.java
Commit message (Collapse)AuthorAgeFilesLines
* Polish RemoteInputView defocus animationJohannes Gallmann2023-01-111-4/+3
| | | | | | | | | | | | | This CL polishes the defocus animation of the RemoteInputView: 1. The action container (containing "Reply"-button etc.) is cross faded with the RemoteInputView. 2. Some animator start delays are adjusted. 3. The animate flag is activated in the reset() function. The reset() function is called e.g. when a text message is sent and the RemoteInputView disappears. Some code restructuring was necessary for this change because parts of the reset() function need to be executed after the animation is finished. All three changes are added behind the already existing inline-reply-animation flag. Bug: 174148449 Test: atest RemoteInputViewTest, Manual, e.g. analyzing screen recordings (together with Dimitri) of defocus animations after text messages are sent. Change-Id: Ifc128917c1277908c2147abaf1669432d0249edb
* Merge "Update SysUI to use new PowerManager WakeReasons" into tm-qpr-devBeverly Tai2022-12-221-3/+5
|\
| * Update SysUI to use new PowerManager WakeReasonsBeverly2022-12-201-3/+5
| | | | | | | | | | | | | | Test: manual - check PowerManagerService logs Test: atest CentralSurfacesImplTest PulsingGestureListenerTest Bug: 242628816 Change-Id: I9ff9845a1f98beb336993170ce65886a31dbfdb9
* | Reapply changes of inline reply CLJohannes Gallmann2022-12-211-3/+0
| | | | | | | | | | | | | | | | Just before merging ag/20462188, I had to change the flag ID because there was a conflict. Unfortunately, a very stupid mistake happened during this minor fix. I changed the flag ID in an old version of the CL and uploaded that old version (as can be seen in the changelog of the latest uploaded patch in that CL). Therefore, this CL reapplies all changes that were undone in the latest patchset of ag/20462188 and ag/20462188. Bug: 174148361 Test: atest RemoteInputViewTest, Manual, i.e. posting various types of Notifications from the Notify2-RVC application with a reply action added to them. Then observing the animations visually and analyzing frames from screen recordings. Change-Id: I0f9deb15e8fae361ef6ebb6ff0119d2ee6888372
* | Fix notification inline reply animationJohannes Gallmann2022-12-191-1/+5
|/ | | | | | | | | | | | | | | | | | This CL fixes the animation for the appearance of the inline reply RemoteInputView, bringing it as close to the Direct spec (https://direct.googleplex.com/#/spec/283080003) as possible. Intentional deviations from the Direct specs are the following: 1. The animation duration is 360 ms instead of 500 ms (in order to be consistent with other notification shade resize animations) 2. The interpolator is FAST_IN_SLOW_OUT, which might differ slightly from the Direct specs "DECELERATE_WITH_EASING" interpolator. (same reason as for 1.) 3. The height of the notification is increased slightly more than in the Direct spec. (This is done in order to keep the paddings and margins as they currently are. It seems to me that if there was more text in the Direct visualization, the top margin of the inline reply EditText would be too small.) This CL does not fix the following related issues: 1. The collapsed heads up view does not allocate enough space to fit the RemoteInputView. This causes the top part of the notification to get shrunk (Icons jump up by a few pixels), when clicking the "Reply" button. It also affects the beginning of the RemoteInputView expand animation to be partly shifted out of the HeadsUp View. 2. When defocusing the RemoteInputView, the "Reply" button is clipped during the beginning of the animation. 3. When focusing the RemoteInputView, the notification shade is not scrolled correctly. (Keyboard is overlapping RemoteInputView) 4. The expand/collapse animation is broken while the RemoteInputView is visible. I will address these issues in seperate CLs. Bug: 174148361 Test: atest RemoteInputViewTest, Manual, i.e. posting various types of Notifications from the Notify2-RVC application with a reply action added to them. Then observing the animations visually and analyzing frames from screen recordings. Change-Id: I8b2e821b254d6d7fdfbca22426eceafff95d5322
* Remove NotifEntryManagerSteve Elliott2022-08-311-22/+0
| | | | | | | Bug: 200269355 Test: atest SystemUITests Change-Id: I3e418dfd7d3512ac811e67733e32818622a0a415 Merged-In: I3e418dfd7d3512ac811e67733e32818622a0a415
* Remove dead code from NotifEntryManagerSteve Elliott2022-08-121-247/+0
| | | | | | | | | | | | All removed code is unused; since all changes are relegated to NotificationEntryManager.java, if this CL still builds, it is proof that the code in question was not referenced anywhere (assuming no reflection). Bug: 200269355 Test: atest SystemUITests Change-Id: If24a9a92c6af5c2edd4fe1b628bb720a6a12a311 Merged-In: If24a9a92c6af5c2edd4fe1b628bb720a6a12a311
* Inline notif pipeline flag in NotifRemoteInputMgrSteve Elliott2022-06-301-44/+6
| | | | | | | | | | This change is a no-op; the flag is now enabled-by-default, so all removed code paths here are effectively dead. Bug: 200269355 Test: atest SystemUITests Change-Id: Ifa554b42821c35860add7f7538658c5a48384c66 Merged-In: Ifa554b42821c35860add7f7538658c5a48384c66
* Remove HeadsUpCoordiator's lifetime extension on action press.Jeff DeCew2022-05-251-0/+15
| | | | | | Fixes: 233864220 Test: atest HeadsUpCoordinatorTest Change-Id: I10ca619b2d863d35c3c8204561081aa6479146d2
* Rename CentralSurfacesInt back to CentralSurfaces.Dave Mankoff2022-04-281-3/+3
| | | | | | | | | Necessary step to retain git history of CentralSurfacesImpl. Bug: 229228871 Test: manual Change-Id: If4152279970090eeb3ea34307dfade5873e9dbf3 Merged-In: If4152279970090eeb3ea34307dfade5873e9dbf3
* Make CentralSurfaces an Interface.Dave Mankoff2022-04-281-3/+3
| | | | | | | | | | | | | | | CentralSurfaces is now an interface. It is a very large and ugly one. This allows us to remove the provider in StatusBarPhoneModule, and will make it easier to control how the Optional for CentralSurfaces is setup. It is renamed CentralSurfacesInt temporarily to allow maintenance of the blame and history of CentralSurfaces in CentralSurfacesImpl. Bug: 229228871 Test: atest SystemUITests && manual Change-Id: Iab41b70e0c65d75560010d961dcb52a11fd237f5 Merged-In: Iab41b70e0c65d75560010d961dcb52a11fd237f5
* Remove FileDescriptor from systemui.Dumpable.Dave Mankoff2022-04-051-4/+3
| | | | | | | | | | This is the first step in moving over to the new public android.util.Dumpable api. Bug: 217567642 Test: m SystemUI Merged-In: Ibaebcfb2c6c5326d0c45b8c72d868c76655d89a0 Change-Id: Ibaebcfb2c6c5326d0c45b8c72d868c76655d89a0
* [RemoteInputView] move data fields to ControllerSteve Elliott2022-03-141-3/+2
| | | | | | | | | These fields were used to track some non-View-related data for RemoteInputs. Test: manual Bug: 193539698 Change-Id: I220060d0ab9e77bdba6f8aa9956b27cc0b1183d8
* [Status Bar] Re-name StatusBar.java -> CentralSurfaces.java.Caitlin Cassidy2022-02-281-8/+8
| | | | | | | | | | | Also add some javadoc to CentralSurfaces.java to make its purpose slightly clearer. Bug: 197137564 Test: compiles Test: atest SystemUITests Change-Id: Id06e7ba7641d6d2bc276cce57101c9c7236bc758 Merged-In: Id06e7ba7641d6d2bc276cce57101c9c7236bc758
* Improve RemoteInputManager dump.Jeff DeCew2021-11-291-1/+13
| | | | | | | | This dump information would have given me better insight into the referenced bug Bug: 208255329 Test: manual dumping Change-Id: Ie9a63aa261ff23358bc126ce12ad854d1068bf08
* Inline most FeatureFlags methods.Dave Mankoff2021-11-171-7/+7
| | | | | | | | These methods are better off inline. Bug: 203548827 Test: manual Change-Id: I83b4d15d5915696519c94752c446978003b0679e
* [RemoteInputView] Move "send" logic to ControllerSteve Elliott2021-11-121-2/+6
| | | | | | | | Bonus: removes the BouncerChecker from the View Bug: 193539698 Test: receive notification and reply via RemoteInput Change-Id: Ifea0e4a39de90aca84bfc9c3e6718cc7a87c1152
* New Pipeline: Add a NotificationVisibilityProvider to support both pipelinesJeff DeCew2021-11-091-8/+5
| | | | | | | | Fixes: 169655596 Fixes: 204183781 Fixes: 204770080 Test: atest SystemUITests Change-Id: I96cd96d1a037e7cca301242b1dba25ecdd72be9a
* New Pipeline: Remote Input 4/4: Add RemoteInputCoordinatorJeff DeCew2021-10-301-10/+37
| | | | | | Fixes: 203938360 Test: atest SelfTrackingLifetimeExtenderTest RemoteInputCoordinatorTest NotificationRemoteInputManagerTest Change-Id: I342a09ef71a223b24db075e5f2ef68a6950ff32b
* New Pipeline: Remote Input 3/4: Extract notification rebuilder methods to a ↵Jeff DeCew2021-10-301-82/+5
| | | | | | | | utility Bug: 203938360 Test: atest RemoteInputNotificationRebuilderTest Change-Id: I80ace34e5e97e5ccc6135276b83102f5696dd23b
* New Pipeline: Remote Input 1/4: Extract legacy pipeline logic within ↵Jeff DeCew2021-10-301-215/+324
| | | | | | | | NotificationRemoteInputManager Bug: 203938360 Test: atest NotificationRemoteInputManagerTest SmartReplyControllerTest Change-Id: I5424d3525601fda2b217c3d13130769106d4f50d
* Manually register Dumpables to DumpManagerNed Burns2021-09-081-1/+5
| | | | | | | | | | | | | | | | 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
* Move mRemoteInputManager + logic to ControllerSteve Elliott2021-07-211-12/+50
| | | | | | | | Part of an effort to refactor NSSL for uni-directional data flow. Bug: 193539698 Test: manual Change-Id: I6be3a9d9f84d2bf87e0240b88010e7484967b39f
* Make StatusBar purely optionalTadashi G. Takaoka2021-07-151-7/+9
| | | | | | | | | | | | | | | To be able to inject Optional.empty() to Optional<StatusBar>, this CL - removes raw StatusBar references and replaces it with Optional<StatusBar> - replaces Optional<Lazy<StatusBar>> to Lazy<Optional<StatusBar>> Bug: 144309772 Bug: 138625582 Bug: 187111275 Bug: 187111293 Test: atest SystemUITests Change-Id: I07b63e417dd4cc75a17951619065ba0f234bc2aa Merged-In: I07b63e417dd4cc75a17951619065ba0f234bc2aa
* Persist remote input image attachment across layoutsSteve Elliott2021-06-291-4/+4
| | | | | | | Fixes: 188646667 Test: manual, atest Change-Id: I85f7726c4b8c1bfcf64a1ff3f4be092e970747ae Merged-In: I85f7726c4b8c1bfcf64a1ff3f4be092e970747ae
* Fix NPE in logActionClick when we were re-fetching the NotificationEntry we ↵Jeff DeCew2021-06-101-4/+2
| | | | | | | | already had. Fixes: 189234737 Test: click a bunch of actions Change-Id: I295eaadbef9f31b10e92f6d04d80cfe367a22af0
* Fix NPE when NotificationEntry can't be found for action tapJeff DeCew2021-05-111-2/+6
| | | | | | Fixes: 187840537 Test: tap some actions Change-Id: Ie9282295415821bff0fe3bb7cd0b96ef0fe184b8
* Fix "Mark as Read" bug.Jeff DeCew2021-04-301-3/+19
| | | | | | | | When a notification has had its lifetime extended by the NotificationRemoteInputManager$RemoteInputHistoryExtender, we will now terminate that lifetime extension 200ms after any other action has successfully started a PendingIntent. This gives apps 200ms to update the notification without the user seeing anything, and should otherwise prevent the 'dead notification' problem. Bug: 183025105 Test: Use inline notification reply or smart replies for an app which cancels the notification on reply. Then tap "mark as read" or "done" on the notification. Notice that the notification now disappears. Change-Id: I627aaaacf4caee98cc6e282da8f2d0f2bd42bffb
* Don't use WINDOWING_MODE_FULLSCREEN_OR_SPLIT_SCREEN_SECONDARYWale Ogunwale2021-04-161-2/+0
| | | | | | | | | | Temp. solution to get the build going. This is okay as we need to remove this option anyways since we are now using WindowContainerTransaction#setLaunchRoot Bug: 185192439 Test: manual Change-Id: I5b7fa6c9ddb57b74af4b8e0862723e1f7c4e72bd
* Fix keyboard remain after dismissing notificationWilson Wu2021-03-291-0/+1
| | | | | | | | | | | | | | | | | | | | We introduced mRemoteEditImeVisible checking in RemoteInputController#removeRemoteInput by CL[1] to resolve a IME layer issue. Update this flag when remove notification to remove the active remote input. [1]: I7dbc8e656505f79b1bfb198c458d3b95a645c1cb Fix: 183678882 Test: Manual test with bug flow 1) Receive a chat notification 2) Tap direct reply to show the keyboard 3) Swipe to dismiss notification 4) Verify the keyboard will be dismiss as expected Test: atest NotificationRemoteInputManagerTest Change-Id: I7c1af7f0f26906361aa29425fb77e94e5ed4cd12
* Fix bad cast when querying remote input historySteve Elliott2021-03-151-18/+14
| | | | | | Fixes: 171599307 Test: manual, atest Change-Id: I1203e49365eb54b1cdcded653e0b0b51d221558b
* Add checked change APIs to RemoteViewsStevie Kideckel2021-02-171-9/+10
| | | | | | Bug: 179245670 Test: built sample app to use APIs with and without collections, atest Change-Id: I5474bfb7dc15d559867063d1d8516b8ca2ef9755
* Add RemoteInput auth bypass flowSteve Elliott2021-02-081-36/+108
| | | | | | | | | | | | | | | | | | | | | This change adds a way for a RemoteInputView activation to be allowed even when the device is locked. If this is done, then authentication will be deferred until the RemoteInput is sent. At that time, if authentication is still necessary, the bouncer will be shown. Authentication can be bypassed asynchronously while the RemoteInputView is active via the AuthBypassPredicate passed to NotificationRemoteInputManager#activateRemoteInput. If this predicate returns true at the time that the RemoteInput is sent, then the send will succeed, but the device will remain locked. If it returns false, then the bouncer will be shown, at which point the user can choose to unlock the device and send again, or dismiss the bouncer (and nothing else will happen). Test: manual Bug: 170647553 Change-Id: Ie3b2089cefc6cfc2f5b6d218a61a51b1785ecf92
* Move NotifEntryMan and NotifPipeline from NSSLDave Mankoff2020-09-101-0/+1
| | | | | | | | | | | | Move NotificationEntryManager and NotifPipeline from the NotificationStackScrollLayout and into the NotificationStackScrollLayoutController. This cleans up some lingering imports that were hanging about as well. Bug: 147245740 Test: atest SystemUITests && manual Change-Id: I9709e3f67e704458b0e12f7939b569ee387c0fd1
* Allow apps to require auth before triggering actionsJulia Reynolds2020-08-101-23/+35
| | | | | | Test: atest; cts in topic Bug: 162100703 Change-Id: I25354858104eb7fbb343dbb006cd8bf9e48ae3e1
* Fix NPE in NotificationRemoteInputManager loggingNed Burns2020-06-261-2/+2
| | | | | | Test: atest Bug: 159690333 Change-Id: I9e0edbea718961a87f7210a7f390ea0b3b5b8e13
* Merge "Create a shim for StatusBarManager click methods" into rvc-devTreeHugger Robot2020-05-201-5/+4
|\
| * Create a shim for StatusBarManager click methodsEvan Laird2020-05-181-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `StatusBarManager#onNotificationClick` and `StatusBarManager#onNotificationActionClick` are signals we send to system server about notification clicks. This CL adds a shim so that we can have an in-process callback about the exact same events. This CL also adds NotificationInteractionTracker, which basically just merges the NotificationClickNotifier callbacks with the notification collection and will be able to answer the question "has the user interacted with this notification" Lastly, this modifies the logic in ForegroundServiceLifetimeExtender which now checks the interaction flag for notifications. So if a user tapped on a notification action (for instance) which _then_ triggers a notification cancel, it will succeed. It _does not_ as of yet release the notification from lifetime extension upon interaction. So if a notification is canceled and then interacted with, it will still live the full amount of time. Test: atest SystemUITests Bug: 144324894 Change-Id: I42201d6e7b7ffe9ad4f19c774b638a36a51750ef
* | Unlock the work profile for remote inputEran Messeri2020-05-201-5/+26
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change addresses the following scenario: * The device has a managed profile. * The managed profile has a separate challenge from the primary profile (i.e. not a unified challenge). * The user gets a notification from the managed profile. * The notification offers the ability to reply from the lockscreen (e.g. reply to a chat message from the managed profile). In that case, the user should be required to unlock both the primary lockscreen and the managed profile lockscreen, before they can use the inline reply feature. But prior to this change, the user is only asked to unlock the primary lockscreen and then can not proceed. Change the code that handles this scenario to differentiate between unlocking the primary user and unlocking the managed profile by evaluating whether the parent user of the managed profile is locked or not. If the work profile is locked but the primary user is not, then the callback to unlock the work profile is called. Testng steps: * Set up a device with a work profile. * Set a separate challenge to the work profile. * Send a Chat or Hangouts message to the account in the work profile. * From the lockscreen, or notification shade, expand the notification and tap reply. * Observe the user has to unlock twice and gets to enter the reply. Test: Manual (See above) Bug: 149218396 Change-Id: Iea13d08b9fc2d541b78c03d7e695461eb57496b9
* Log clicks on notification actionsNed Burns2020-05-151-8/+19
| | | | | | | | | Add buffer logging for the various stages of clicking on a notification action. Bug: 112656837 Test: atest, manual Change-Id: I2f4803d2e3973a92f9ca24773eedc3ee6a3b1d59
* Show snoozed conversations in conversation headerJulia Reynolds2020-02-281-1/+2
| | | | | | | | | | | | | | | - And allow them to be unsnoozed with a tap. - Also use the conversation's shortcut icon and name if available. - And ignore the setting to turn off the strips since it now requires explicit user action to make the strip visible Note 1: unsnoozing a notification causes it to make sound again - we probably want to change that for manually unsnoozed things Note 2: the entries in the header don't yet persist across a reboot Test: atest, manual Bug: 149486431 Change-Id: Id661c25a49bc982e39deab977eb912f51eaf6757
* Introduce StatusBarModuleSergey Nikolaienkov2020-02-141-5/+4
| | | | | | | | | This CL is the 3rd in the series of CLs which intend to "unbind" StatusBar on TV. In order to make StatusBar really optional and thus to allow us to unbind it, we also need to make some of the classes that depends on it optional as well. For all these cases we need to move from @Inject-annotated contructors to @Provides annotated methods. For this we are introducing StatusBarModule, as well as StatusBarPhoneDependenciesModule and StatusBarDependenciesModule - these two provide dependecies needed to build StatusBar, but not the StatusBar itself Change-Id: Ie3551bda7056465159f2c7fde4989e009f277304 Test: make SystemUI; atest SystemUITests Bug: 146188087
* Show RemoteInput images in notification history.Aran Ink2020-01-221-14/+28
| | | | | | | | For cases where we can't show images, show "Image inserted" text instead. This will happen for work profile notifications, and for notifications that don't use MessagingStyle. Test: Updated unit tests for NotificationRemoteInputManagerTest to use new RemoteInputHistoryItem structure, and to ensure support for URIs and mime types. Manual testing to ensure images appear in notification history for MessagingStyle notifications under the primary user, and that "Image inserted" appears for work-profile and non-messaging notifications. Change-Id: I254b579aa710337039a7def6880f14a61bbd4d53
* Convert NotificationContentInflater to singletonKevin Han2020-01-081-1/+9
| | | | | | | | | | | | | | | | Convert NotificationContentInflater into a singleton since it has almost no state, making it easier to inject and re-use. Move the only per-row state it has, cached remote views, to a separate class NotifRemoteViewCacheImpl that manages the lifetime of the cached remote views based off the notification's lifecycle. This has the added benefit of being re-usable for content recycling later on. Bug: 145749521 Test: atest SystemUITests Test: atest NotificationContentInflaterTest w/o @Suppress locally Test: smoke test Change-Id: Iedda71d7e5edea9e30580e99eb5b6ec545bb708d
* 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
* Move dozing related methods out of ShadeControllerHeemin Seog2019-12-091-5/+5
| | | | | | | | | | | isDozing is already provided by StatusBarStateController. wakeUpIfDozing doesn't need to be in ShadeController and can stay in StatusBar for now (potentially move into a dozing related controller in the future?) Bug: 144702768 Test: manual, atest SystemUITests Change-Id: I8f7d6a452388308de5fdd1adfbcd200fd3076a2f
* Remove ENR.mStatusBarNotificationNed Burns2019-11-151-1/+1
| | | | | | | | | | There was no need to hang on to this field as it's stored in mEntry. Also inlines all calls to getStatusBarNotification() to getEntry().getSbn() Test: atest Change-Id: I3b9adcf91c6925ce78a787273653ca5b484d07e2
* Remove NotificationDataEvan Laird2019-11-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Track and destroy inline URI grants separately from Notification URIs.Aran Ink2019-11-041-2/+6
| | | | | | | | | Bug: 142492493 Bug: 137398133 Test: Unit tests pass. Manual testing with an app configured to receive images via RemoteInput can access and display image URIs after the notification has been canceled, but before the notification entry has been removed from the shade. Change-Id: If64ae7eff7293df3317a1f629977aaaccd866b32
* Move DI related coded into new dagger package.Dave Mankoff2019-10-211-4/+2
| | | | | | | | | This adds new Dagger qualifiers for BgHandler, BgLooper, MainHandler, MainLooper, and MainResources, replacing the use of @Named for them. Bug: 142954072 Test: atest SystemUITests Change-Id: Ibbda8998e587474c26740ba8d49a8b3f90d89efa
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-12 01:31:11 +0000