- If a user taps the PiP quickly multiple times, you can hit a case where
you expand the PIP, which triggers the re-registration of the
InputConsumer, but doesn't disable touches until the pinned stack
animation starts. If the user taps in between that time, it can trigger
a resizing of the stack what aborts the expand animation
- Also adding additional debugging logs
Bug: 37657050
Test: Quickly tap the PiP
Change-Id: Ib0088a3aa8e917aca3214c289a0787bdf7e66199
Notes:
- Subclasses of KeyguardIndicationController can now provide indication text
to be displayed when a trust agent is managed.
Test: runtest sysui
Bug: 38397982
Change-Id: I1b7ee3041aceae94d12da25608f8e7b2e9ebbbe2
Otherwise all unlocks will result in onDismissCancelled.
Also fixes a race condition bug where we call
reportKeyguardShowingChanged but we don't wait until the state is
updated. Then, we called onDismissSucceeded such that
KeyguardManager.isDeviceLocked would still return true. Fix this
by waiting for the message to be processed.
Note that delays shouldn't be a problem here as we are soon
calling reportKeyguardShowingChanged from the UiOffloadThread.
Test: KeyguardLockedTests
Change-Id: I0b312a5f02be3a3d1028d8bf0cd1b8e6a33476ce
Fixes: 38219395
Latency when unlocking the phone regressed a bit for two reasons:
- For lockscreen -> app we now have to create a full starting
window containing the snapshot, while previously this was just
showing a surface.
- For lockscreen -> home, we can't use the saved surface anymore
because currently we don't support snapshotting translucent
activities. However, in the long term, we want home screen to be
more involved into transitions anyways, so we'll have to wait for
the first frame draw anyways.
However, crystal ball trainee developer Jorim added some
artificial latency in this transition 3 years ago, because he knew
that it is going to be an issue at some point so we have some
headroom to improve! Genius! On a more serious note, it was because
he didn't understand how to read systraces with binders involved (to
be fair, there was also no binder tracing).
Now, we can completely fix the introduces latencies above by
removing this latency of 100ms, and we are 30-70ms better than
before! However, this requires a lot of discipline in SystemUI.
Currently, the callback to dismiss Keyguard takes around 30ms. By
moving all non-essential binder calls of the main thread or to the
next frame, we bring this down to 5ms, such that window animation
and Keyguard animation starts about at the same time.
Test: Take systrace, unlock phone...profit!
Fixes: 38294347
Change-Id: I481fe4ecf358ed09f7142dd9e7ecd290b53c500c
Merged-In: I3ea672bc2eca47221bc6c9f3d7c56b6899df207d
Latency when unlocking the phone regressed a bit for two reasons:
- For lockscreen -> app we now have to create a full starting
window containing the snapshot, while previously this was just
showing a surface.
- For lockscreen -> home, we can't use the saved surface anymore
because currently we don't support snapshotting translucent
activities. However, in the long term, we want home screen to be
more involved into transitions anyways, so we'll have to wait for
the first frame draw anyways.
However, crystal ball trainee developer Jorim added some
artificial latency in this transition 3 years ago, because he knew
that it is going to be an issue at some point so we have some
headroom to improve! Genius! On a more serious note, it was because
he didn't understand how to read systraces with binders involved (to
be fair, there was also no binder tracing).
Now, we can completely fix the introduces latencies above by
removing this latency of 100ms, and we are 30-70ms better than
before! However, this requires a lot of discipline in SystemUI.
Currently, the callback to dismiss Keyguard takes around 30ms. By
moving all non-essential binder calls of the main thread or to the
next frame, we bring this down to 5ms, such that window animation
and Keyguard animation starts about at the same time.
Test: Take systrace, unlock phone...profit!
Change-Id: I3ea672bc2eca47221bc6c9f3d7c56b6899df207d
Fixes: 38294347
- The secondary SystemUI process's KeyguardUpdateMonitor is not updated
so we can't rely on it to get the current user id.
Bug: 38372598
Test: Switch users, launch some tasks, and switch back. Ensure that original
tasks still exist
Change-Id: I26a7c70b5f7032a106dc1342c8b366e4797e8fa0
- Use same strategy to draw thumbnail bitmap by moving
startActivity off from the main thread and start caching the future
when AM is busy executing startActivity.
- Move some binder calls off the main thread.
- Add some trace points for better analysis in the future.
- Make toggleRecentApps asynchronous so we don't have to wait on
the next app-vsync - it's totally not needed.
Test: com.android.apptransition.tests.LatencyTests
Fixes: 32668632
Change-Id: Id6483e26e9d6c1e319bceaa8268da976cedfbca3
Merged-In: I15db41f2e821779972ab3b430033c70aa1dfd907
- Use same strategy to draw thumbnail bitmap by moving
startActivity off from the main thread and start caching the future
when AM is busy executing startActivity.
- Move some binder calls off the main thread.
- Add some trace points for better analysis in the future.
- Make toggleRecentApps asynchronous so we don't have to wait on
the next app-vsync - it's totally not needed.
Test: com.android.apptransition.tests.LatencyTests
Change-Id: I15db41f2e821779972ab3b430033c70aa1dfd907
Fixes: 32668632
- We were just finishing the activity which was causing issues with the
wrong app transition being applied. We actually can just hide the menu
activity first before finishing it like we do elsewhere.
Bug: 38222481
Test: Open PiP, launch to show assistant
Change-Id: I348f8a17f76006bcef46fe01c87deae0b89f6586
- Previously we were (incorrectly) assuming that the creation of the
BackgroundTaskLoader would be followed synchronously by a call to start()
the background loader itself. However, now that we post the start of
the loader, the run() call can be made before the start() call.
Bug: 38310660
Test: This is an intermittent bug, hard to repro.
Change-Id: I4dfd18b8c3c127429c790177e98ca41ec70f493d
Rearrange how we generate the transition specs, which involves
creating a thumbnail on the mainthread (about 10ms on large
devices): First, we put launching the activity onto a handler
thread (with default priority), to free up the main thread. Then,
we immediately start generating the thumbnail such that when the
future calls us we have the generated spec already handy.
For that we need to be able to supply a specs future into
ActivityOptions, to avoid race conditions. Furthermore we need to
make sure not to call into WM while creating specs, to avoid WM
lock contention.
Test: App -> Recents -> Same app, inspect app transition logs
Test: Double tap recents for quick switching
Bug: 32668632
Change-Id: I6001e29145f8e56deb9c4ead46c53c87c9191436
Merged-In: Ic6ec65c2560f67cade3b5ddde9f79ee13e9ba32c
Rearrange how we generate the transition specs, which involves
creating a thumbnail on the mainthread (about 10ms on large
devices): First, we put launching the activity onto a handler
thread (with default priority), to free up the main thread. Then,
we immediately start generating the thumbnail such that when the
future calls us we have the generated spec already handy.
For that we need to be able to supply a specs future into
ActivityOptions, to avoid race conditions. Furthermore we need to
make sure not to call into WM while creating specs, to avoid WM
lock contention.
Test: App -> Recents -> Same app, inspect app transition logs
Test: Double tap recents for quick switching
Bug: 32668632
Change-Id: Ic6ec65c2560f67cade3b5ddde9f79ee13e9ba32c
The color extraction algorithm is tuned further:
We're now regarding more colors as white when
it comes to the background selection.
For muted color swatches we also factor in the popuplation.
Finally, we also factor in the mostdominant color to overtake the text
color in case it is very dominant.
Test: runtest systemui
Bug: 38168152
Change-Id: I858017b83559255ead48c3ab6c3bc16ed110e57c
Also, clear heads-up entries when switching to notifications panel. Auto
does not want any notifications to be pinned to the top.
Test: booted up android auto headunit
Bug: 33210494
Change-Id: If722a887f4bc0d4a91ca37d4e7de5af94ca0f8dd
Fixes an issue where canceling the time tick
alarm was not done properly, which then prevented
the alarm from being scheduled again.
Change-Id: I233f6227eabc65ea1cd13e7c53930573fb552126
Fixes: 36506772
Test: runtest -x packages/SystemUI/tests/src/com/android/systemui/doze/DozeUiTest.java
There's a race condition if user unlocks from bouncer and an app underneath
uses FP does onResume()
If a user has an application that's authenticating via FP underneath
keyguard and the user dismisses keyguard via bouncer, the app underneath
will get kicked out since onKeyguardVisibilityChanged(false) calls
shouldListenForFingerprint() during this race.
Keyguard shouldn't listen to FP if bouncer is showing but keyguard is
dismissing
Fixes: 37967985
Test: 1) open FP settings
2) enter keyguard and go to bouncer
3) unlock keyguard via pin/pattern/password (NON FP method)
4) tap any finger on sensor (should vibrate)
Merged-In: Ie38d55e6a1ec9b49f9df0c7520d0bc451315c161
Change-Id: Ie38d55e6a1ec9b49f9df0c7520d0bc451315c161
touching view hierarchy should only occur on UI thread
Bug: 37167272
Test: keyguard still works, used Log to see that switching
still gets called
Change-Id: I45ed9894a8f08c38da40de44f84e99cddb683014
