- When Transitions migrated to ShellInit, the default/remote handlers
got added after PipTransitionController (which should really also
use ShellInit (to be fixed in a follow up CL)). For now, we can
be explicit about where they should be added in the list.
Bug: 241515409
Bug: 241484248
Test: atest PinnedStackTests
Test: atest WMShellFlickerTests:com.android.wm.shell.flicker.pip.AutoEnterPipOnGoToHomeTest
Change-Id: I696327004e06e7ddd402a509fa18c86c60b244d4
There are already animations for most of these operations (eg. in
launcher), so instead of "claiming" the transition animation
and doing nothing, this should just update state (window decor)
and then let other handlers play the animations.
Bug: 241486751
Test: launch app from launcher, go back.
Change-Id: Ic5d01b76c04d6adab484d53d24d1a89b001a4c80
android.os.Trace#beginSection limits the length of the section to 127,
otherwise, a IllegalArgumentException throws. We limit the length before
passing the argument to avoid this.
Bug: 239860117
Test: atest InteractionJankMonitorTest FrameTrackerTest
Change-Id: I3d9cbc65a8036c18680edf11aace0b324a1befb6
KeyguardUpdateMonitor uses WeakReference internally for all the
registered callbacks, therefore an anonymous class may be released and
unable to receive any callback after registration.
Changed also the ConfigurationListener and
KeyguardStateController.Callback in WMShell.
Bug: 241249835
Test: repeatedly lock and unlock device with PiP being present
Change-Id: I1c3ea269ee9955847212bebbebdd0d7130dbdce5
- Don't expand shade if touch started from KG and then
ended when KG was not longer showing. This can happen
if the security setting is set to swpe to open,
and the user transitions to the SHADE. Then, the touch can
be canceled if a window is transitioning to landscape.
- Don't propagate notification panel expansion to the bouncer
when the device is unlocking with biometric (MODE_DISMISS_BOUNCER).
Since KeyguardBouncer.EXPANSION_VISIBLE = 0 panel expansion, calls
during the unlock transition to collapse the notification panel
unintentionally end up showing the bouncer.
- If the KG isn't showing and the bouncer is in transit, reset the
bouncer expansion to HIDDEN.
Test: open fruit ninja (which is locked to landscape)
and swipe to unlock, notice that panel does not expand on unlock
Test: unlock using udfps by sliding finger from slightly below/diagonal
of the UDFPS sensor (so that the bouncer transition begins), and then
successfully authenticate with UDFPS => observe the bouncer UI doesn't
flash on the screen after successful authentication.
Test: atest StatusBarKeyguardViewManagerTest
Fixes: 240487038
Fixes: 240763673
Merged-In: I9e1fb108147ffb4c812ea2b94a50d6201eaf008a
Change-Id: I9e1fb108147ffb4c812ea2b94a50d6201eaf008a
The bouncer refactor changes some of the existing behavior. To add an
easy way to revert back to the old behavior, we want to enable/disable
the refactor with a feature flag.
Bug: 240299776
Test: None as this does not change any behavior
Change-Id: I1335325599a554d5d98a2a840169191540165672
Merged-In: I1335325599a554d5d98a2a840169191540165672
These were used in the past to collect data for the FalsingManager
and are no longer used.
Fixes: 218350933
Test: manual
Change-Id: Ib35dfeb4c879353aa0fb6daf83691b9189d12c6c
> Generating only one bitmap when creating appIcon
> Extracting the scale during icon generation for main icon
instead of running icon normalizer again
> Avoiding unnecessary color extraction on main icon
Bug: 238937089
Test: Verified on device
Change-Id: Ia01801f15e5982593852f05c2512d0f1f737f5f7
Currently, when the New Back Arrow is flung and the finger lifted, we do
not actually send the trigger event -- but we do if the finger is lifted
after coming to a "stop", i.e., a commit without a "fling".
To test, swipe from the right edge inwards, and release while your finger is in motion (as opposed to "stop moving, and then lift").
Bug: 240272871
Test: Manual
Change-Id: I81d6e6b1bb42c2cd12d14ae861ba8eb9f3081d11
After PUK unlock, multiple calls to
KeyguardSecurityContainerController#dismiss() were being called from
the KeyguardSimPukViewController, which begins the transition to the
next security screen, if any. At the same time, other parts of the
system, also listening to SIM events, recognize the PUK unlock and
call KeyguardSecurityContainer#showSecurityScreen, which updates which
security method comes next. After boot, this should be one of PIN,
Password, Pattern, assuming they have a security method. If one of the
first dismiss() calls comes AFTER the security method changes, this is
incorrectly recognized by the code as a successful
PIN/pattern/password unlock. This causes the keyguard to be marked as
done, causing screen flickers and incorrect system state.
The solution: every call to dismiss() should include a new parameter
for the security method used. If there is a difference between this
parameter and the current value in KeyguardSecurityContainerCallback,
ignore the request, as the system state has changed.
Fixes: 238804980
Bug: 218500036
Test: atest KeyguardSecurityContainerTest
AdminSecondaryLockScreenControllerTest KeyguardHostViewControllerTest
KeyguardSecurityContainerControllerTest
Change-Id: I7c8714a177bc85fbce92f6e8fe911f74ca2ac243
Merged-In: I7c8714a177bc85fbce92f6e8fe911f74ca2ac243
* changes:
Remove remaining references to COMBINED_STATUS_BAR_SIGNAL_FLAGS
Revert^2 "Remove support for COMBINED_SIGNAL_ICONS"
Revert^2 "Create a MobileStatusTrackerFactory"
Revert^2 "Change from deprecated telephony api"
Revert^2 "[Cleanup] Order NetworkController's intent filters"
Revert^2 "Add an @Inject-able MobileSignalControllerFactory"
Fix state update in onRoutingUpdated() in case of failure to
communicate to the native spatializer: this can cause an exception later
in setDispatchFeatureEnabledState(). Instead, try to recover by
triggering a reset.
Fix other places where exceptions are thrown instead of just logging an
error or triggering a reset.
Bug: 241018866
Test: make
Change-Id: I2ca01b76d701e7f5db7ba08d159bba843b145e4e
