fitsSystemWindows="true" has default behavior of setting padding of the
view to ensure contents don't overlay system windows. In the case of the
fullscreen user switcher, we don't need this behavior.
Bug: 150302361
Test: Manual (set lockscreen, restart, click "Cancel")
Change-Id: Ifc597c2b96862abc3283d6af1a0c2765431c71af
Prior to this change, KeyguardViewMediator used StatusBarKeyguardViewManager for making view-related changes.
This meant that KeyguardViewMediator could only be used with a specific Keyguard view that is mounted to the StatusBar.
This change makes KeyguardViewMediator compatible with any Keyguard view no matter where it is mounted, as long as it implements
the methods defined in the KeyguardViewController interface.
For AAOS, This refactorization allows us to implements our own Keyguard View and its Manager as the next step.
Bug: 150467593
Test: Build and Manual Test -- Android builds successfully on Hawk and Pixel 2 and interacting with Keyguard functionalities works.
Change-Id: Idda93514eac030f1d92523aebc9444a4d55b21d2
This change includes the following:
* Rename SystemUIPrimaryWindow to SystemUIOverlayWindow
* Create Mediator and View controller abstractions that allows
developers to easily take advantage of SystemUIOverlayWindow that is
managed by a single SystemUI Object: SystemUIOverlayWindowManager.
* Convert FullscreenUserSwitcher to take advantage of the newly added
abstractions.
Bug: 147826738
Test: Manual
Change-Id: I19825da81f8d1b1259a2ba115e0238a9ffa69e37
Merged-In: I19825da81f8d1b1259a2ba115e0238a9ffa69e37
Previously, while restarting the Navigation Bar, we omitted the step where we
apply the selection state that reflects the current task stack.
This omission caused CarFacetButtons to lose their selection state on
certain events.
Bug: 148211695
Test: Unit Test
Change-Id: Icfa845b87ca7456d3765602b3daacd589a94f309
* changes:
Move SB.StateListener from LockIcon to Controller.
Remove the OnUserInfoChangedListener implementation from LockIcon.
Pass LockscreenIconController around instead of LockIcon.
This also makes KeyguardIndicationController properly injectable, and
moves some of the LockIcon touch-handling that was happening inside
of it into the LockscreenIconController.
To make KeyguardIndicationController injectable, a new
WakeLock.Builder was added that can be injected and used to create
new WakeLocks as needed.
Bug: 150393918
Test: atest SystemUITests && manual
Change-Id: I3ad871164a822c0c63c0e32da777beb287144a35
(Cherry-picked from 353ef627803f7b9e5417c7c07659edadf4e8846c)
Bug: 144872669
Test: Build, manually play around with volume settings
Change-Id: Ia5589689e5c37be3898ac1edb2df00b84280cb7d
Merged-In: Ia5589689e5c37be3898ac1edb2df00b84280cb7d
Bug: 147427386
Test: atest SystemUITests for sdk_gphone_x86 and atest
CarNavigationBarControllerTest HvacControllerTest for hawk-userdebug
Change-Id: I9d0ee8135c1a53abaeb64f4b7b2aebd9208c0160
Register a receiver that listens for Intent.ACTION_CLOSE_SYSTEM_DIALOGS
and dismisses the volume UI when such an intent is received.
Bug: 149228466
Test: Manual
Change-Id: Iabb706b1d4cc54cb84f228aad95bfdb7e6f75851
Move the StatusBarTouchableRegionManager to StatusBar where it will be
recreated whenever new views are created (instead of within
HeadsUpManager)
Test: atest SystemUITests
Change-Id: I802ec8ea122a2cede234ec7536f1177f7b261fd0
This CL is the 4th 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 BubbleModule and KeyguardModule.
Change-Id: I57009153e2279078ac88c42a53d3963a96eb8452
Test: make SystemUI; atest SystemUITests
Bug: 146188087
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
This CL is the 2nd 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 StatusBarNotificationModule.
Change-Id: Id56f970d21323f49e859715b6874f5cd773aa62a
Test: make SystemUI; atest SystemUITests
Bug: 146188087
This CL is the 1st 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 expanding NotificationsModule.
Change-Id: Icccafd2170f2fdffb8412370056aab7042ffd580
Test: make SystemUI; make CarSystemUI; atest SystemUITests
Bug: 146188087
CarStatusBar had one last reference in its dump method.
FalsingManager, however, directly registers itself with the
DumpController, so this call is redundant.
Bug: 136279712
Test: atest SystemUITests
Change-Id: I3731e7ecac2f147e5d3967d4219f22d17e810843
Adds a controller for PipControlsView so that depdencies can be provided
via injection.
Adds a TvPipComponent to allow injection of PIP related views into related
classes.
Bug: 146660939
Test: atest SystemUITests
Change-Id: Ic1a8f8f0f8e5506f354bb1f07b179db1d7e89577
First, moves most of the notification initialization logic out of
StatusBar and into NotificationController.
There is only one subclass of NotificationEntryManager in this project:
- CarNotificationEntryManager: stub implementation that disables most
functionality.
Removes CarNotificationEntryManager. Adds a config boolean to disable
notification rendering instead. Skips most notif initialization logic if
this flag is false.
Change-Id: I23ed86efa209f43314c162dcf32fe97112de7bc7
Test: atest, manual
This was lacking from ag/10097974.
Bug: 148388531
Test: HomeHelperTest is included in TEST_MAPPING
Change-Id: I73e9d9bbf6499e4d0c3dc7654118e52f6b3a2950
In order to do that, NotificationManager now calls
StatusBar.showToast(), which is in SystemUI. StatusBar then calls a new
component, ToastUI, which is responsible for rendering the toast. The
code for rendering the toast was extracted from the Toast class, so it
should behave identically.
Also refactored the code a bit on NotificationManagerService, creating
two children of ToastRecord (one for custom, other for text toasts).
The change is gated in Toast class in this CL, but it's also gated on
the system server, so apps can't circumvent the background block.
Bug: 128611929
Bug: 144754526
Test: atest android.widget.cts.ToastTest
Merged-In: Id0021cdc6f72f41b55ff1c5a4f09ae7687586460
Change-Id: Id0021cdc6f72f41b55ff1c5a4f09ae7687586460
Resolves the issue where for Car we switched back to only showing
Phone's implementation of StatusBar rather than Car's.
Bug: 148078465
Test: Manual
Change-Id: Id1b342e3b7a0e9437422c1edd221f320d52927de
When root-level content containers fit insets, they used to just
apply and consume the entire system insets. However, with the new
Inset APIs, and with deprecating ADJUST_RESIZE IME flag, we want
to give apps an easy way to customize this behavior.
For that, we introduce Window.setOnContentApplyWindowInsetsListener
that returns what kind of margins/padding should be applied and
what should be dispatched to the content views. This is essentially
a replacement for SYSTEM_UI_FLAG_LAYOUT_* as well as
SOFT_INPUT_ADJUST_RESIZE: It allows apps to choose which insets
should be handled on the window level vs view level.
For that, we mark the window decor views as
FRAMEWORK_OPTIONAL_FIT_SYSTEM_WINDOWS, in order to distinguish the
case when support library calls makeOptionalFitSystemWindows(). This
is because of two reasons:
- We don't want the listener to be invoked twice.
- We can not do the compat ping-pong between onApplyWindowInsets
and fitSystemWindows. This is because during the ping-pong, the
result of the OnContentApplyWindowInsetsListener would be lost.
However, we still need to do the compat ping-pong for
ActionBarOverlayLayout in the support library (until that gets
migrated to use onApplyWindowInsets), so we have this separate
dispatching path that only gets used for framework optional
fitting views.
Test: WindowTest
Bug: 118118435
Change-Id: I4b514addd9e094163062d651972f85615b4a35db
This is the first step to create another new window for status bar.
Small window => TYPE_STATUS_BAR: The bar on top of screen.
Large window => TYPE_NOTIFICATION_SHADE: Anything else.
Bug: 136993073
Test: build then flash
Test: atest WmTests SystemUITests
Test: atest RegisterStatusBarResultTest InsetsFlagsTest
Manual Test:
- Bouncer can show when leave showWhenLocked activity.
- StatusBar can show when comes HUN in fullscreen mode.
- StatusBar can play enter/leave animation in fullscreen mode.
- Able to drag notification panel when bubble/glow existing.
- Switch to market launcher, and run above tests.
- Drag notification panel from launcher several times and observe it
works fine.
Change-Id: Id9f72cd0e21f01b50d57f02ea60f97c6460926b7
Currently we're using STATUS_BAR_SUB_PANEL windowing layer, but we'll
need to revisit this in the future.
Also the height is calculated by appending the height of the navigation
bar. We'll also need to discuss with the windowing team on how to get
the full height of the display using MATCH_PARENT.
Bug: 147455109
Test: manual (test that the window can hold content with a test screen)
Change-Id: I3b821ec0382515804a4ee80396f15d608467efdf
Part of prepatory work for changes coming to
ActivatableNotificationView.
Bug: 147245740
Test: atest SystemUITests
Change-Id: Id85767ab3365e0da659941f267b5d925d6da9dd9
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
This reverts commit da13c3fd3da28ae39e359f9481eba30b12ec9531.
This includes a fix for the original issue - an NPE in
NotificationPanelView.
Bug: 147295216
Change-Id: Id1a71b0e30aada460a70d738c5451e21dd412a7a
Test: atest SystemUITests
Revert "NoticationPanelView now has a controller."
Revert submission 9930899-b141751146-npv-controller
Reason for revert: b/147295216
Reverted Changes:
I9a92cad63: Refactor PanelView and NotificationPanelView into ...
I454bc4790: NoticationPanelView now has a controller.
Change-Id: Iae9db40e9385e1b88bd2f5f162a5f6d53d91878d
In the (old/current) notification pipeline, NotificationEntryManager
handles inflating views. In the NewNotifPipeline, PreparationCoordinator
will trigger inflation via a NotifInflater and will keep track
of what is/isn't inflated.
If a notification isn't done inflating, then the PreparationCoordinator
will filter it from the NotifListBuilder.
Test: atest SystemUiTests
Change-Id: I7a5c01041312ff179e8c723f66207b3bd042c857
