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 da13c3fd3d.
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
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
Test: Manual - Manually verified that navigation button functionalities are working as expected.
Unit Tests
Bug: 145827784
Bug: 145604656
Change-Id: Ib8f837ba34afbb8d66092a8b851b93c50fa20b26
This actually begins the process of deprecation and removing
UiOffloadThread in favor of using Executors directly.
This CL hits the easiest spots in the code. There are a few
more remaining calls that should be in their own independent CLs.
Bug: 146567476
Test: atest SystemUITests
Change-Id: I2542cc61653f330a1931b15a57e3b7c77d18e2e6
Use a controller to monitor KEY_SETUP_WIZARD_IN_PROGRESS and USER_SETUP_COMPLETE
flags to know when to set CarSysUI bars in an unprovisioned state and prevent
interactions with notification shade.
Bug: 145616123
Test: Manual
Change-Id: Ie035f049e3e9e7cb411fc9553a20e4c09078c121
we plan to forbid hidden API in product partition.
So this app should be moved to /system_ext because it uses hidden API.
It is not permanent, so they can be moved back to /product due to
needs if there isn't hidden usage anymore.
Bug: 137908189
Test: m
Test: check whether device boots successfully
Test: atest SystemUITests
Change-Id: I54f86496d4a0045af3576091cce00e5cd285b4f8
Introduce new APIs in Window/WindowManager.LayoutParams for developers
to decide which types of insets at which side a window should avoid:
setFitWindowInsetsTypes(@InsetsType int types)
setFitWindowInsetsSides(@InsetsSide int sides)
setFitIgnoreVisibility(boolean ignore)
The existing logic in DisplayPolicy.layoutWindowLw uses combinations of
window types, window flags, and system UI flags to decide what frames a
window should have, which is very complex, difficult to maintain, and
should be replaced with the new APIs.
Bug: 118118435
Test: atest InsetsSourceProviderTest InsetsStateControllerTest
InsetsPolicyTest WindowStateTests CommandQueueTest
RegisterStatusBarResultTest InsetsFlagsTest
LightBarControllerTest RegisterStatusBarResultTest
ViewRootImplTest DisplayPolicyLayoutTests
DisplayPolicyInsetsTests DisplayPolicyTests
TaskSnapshotSurfaceTest
Change-Id: I06ddc9d0d2887ba4ded7bb8adbf9c9c0da4bf7b4
UserGridRecyclerView shouldn't be creating UserInfo objects, especially not fake
ones that only serve as placeholder for a String. Guest and Add User buttons in
the user switcher don't correspond to real users, and as such, shouldn't be tied
to UserInfo objects.
This can also lead to bugs because consumers of UserRecord assume UserInfo
corresponds to a real user.
Instead we pass null in these cases, and make UserInfo nullable.
Bug: 144993580
Test: manual
Change-Id: I1c772564c8e9ae65699943f6a2f8c1d2c75f013b
