Add layout mode to KeyguardStatusBarView so that it can behave exactly
as it used to when there is no cutout, but have reasonable behavior when
there is.
Test: visual with/without cutout and with/without multi-user switch
Fixes: 72683977
Fixes: 72388285
Change-Id: I72ae5a581dd9d1884ffaf5332f7490d806d319b5
- input service data needs to be in sync with window service data
- section is generated in under 20 ms well within guidelines
Bug: 74098479
Test: Take bug report and verify contents
Test: mmm -j56 frameworks/native/cmds/dumpstate && \
adb sync data && adb shell /data/nativetest64/dumpstate_smoke_test/dumpstate_smoke_test && \
printf "\n\n#### ALL TESTS PASSED ####\n"
Change-Id: Ida087fa6b0b2e1509b6d9570ab216bacbb1a1863
Toggling bluetooth/wifi/tethering can feel unresponsive due to the time
it takes for these services to become enabled. This change immediately
updates the QS tile UI to reflect the transient enabling state.
Fixes: 73714270
Test: visually tapping on each tile slowly and rapidly
Change-Id: Iec10054f2af4ed78e2ddc2fdcd10245a627ca50a
The main goal is to learn at what x-position users tend to swipe down to
pull the notification/qs shade. To do that, this CL logs the following
data:
- x-location (as 0-100 percent)
- y-location (same)
- device rotation
in PanelView#startOpening(). This should only be logged rarely enough
(once per qs pull) not to spam logs or have any performance impact.
It also currently doesn't collect any data when expanding qs from the
keyguard, but I'm assuming that that particular case is much less
common. Logging could be added later though.
Fixes: 74012876
Test: adb logcat -b events | grep sysui_multi_action; pull notification
shade when device is unlocked and see lines like this:
02-28 12:41:42.060 31783 31783 I sysui_multi_action: [757,1324,758,4,826,413,827,12769,1322,91,1323,0,1325,0]
Change-Id: I9154a808552656d3fe02b1a8f732a4fbba3b09e6
Fix a crash when trimMemory has occurred and then a java
VectorDrawable object is deleted.
Test: Ran Camera app
Bug: 72837472
Change-Id: I4bdc5975a9ceccc09af17edd9905345f97c2660f
If we are moving a stack in split-screen seconardy mode forward, we
need to make sure we move the primary split-screen stack forward in
the case it is current behind a fulscreen stack so both halves of the
split-screen appear on-top and the fullscreen stack isn't cutting
between them.
Mostly a workaround until fix can fix b/70677280 where we would have
a stack as a parent of another stack.
Change-Id: I7d030b80c12771e0370a1fea8e1abf96560a9029
Fixes: 71899050
Bug: 70677280
Test: atest ActivityStackTests#testSplitScreenMoveToFront
