- Changes in the CommandQueue callbacks resulted in the default
implementation of preloadRecentApps() to be called instead of the
actual implementation in the Recents component.
- Removing extraneous methods in the interface called from other parts of
SystemUI.
Bug: 38390446
Test: Launch Recents, ensure that preloading is hit first on touch down on
the button
Change-Id: I28f7ac47eafa76a53343505f3352760e6510c213
- Also ensuring that we don't do additional work for non-current users when
the task stack changes.
Bug: 38390446
Test: Launch Recents in multiple users, ensure that it works and does not
make a binder call to get the current user id
Change-Id: If075675edc3874d809bad30d0aa564a8e59771d3
The interpolator we chose had a very slow easy out where it
generated out frame with mExpandedHeight=0.3 pixels. We add a
check there and stop the animation immediately if this happens.
Furthermore, we just use a simple post when closing the panel
to not add to much latency. The frame will be shown in any case
since we are already in animation/input callback, such that a post
will be executed after the frame has been sent to RT.
Test: Capture trace, unlock phone, make sure no delays
Change-Id: I9fc45f4b081bd6143da1ba99e9bc652a9f64e4a7
Fixes: 38294347
- 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
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
- 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
- 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
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
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
- Start loading things after we drew our first frame.
- Don't load high res task until low res tasks have been loaded:
In case the snapshot is already in cache in system_server the
low-res task loader will load the full res snapshot, leading to
GC pressure due to registerNativeAlloc. Now, if both task loader
load the same snapshot at the same time we are very likely
to trigger a blocking GC alloc.
Test: Open recents, look at systrace
Change-Id: I10c263dc8929742611ad9fbb32f65bc8ac3100bd
Fixes: 36851903
Bug: 32668632
The return result from starting activity actually represents two
pieces of information. First, it conveys whether the activity
started. Secondly, it conveys whether there was a fatal error if
the activity did not start. Many parts of the code assume that a
value greater than or equal to the defined success means that the
activity successfully started. This is not the case as there are a
number of results greater than success where the activity does not
start.
This change addresses the issue by introducing three distinct
result ranges. The first represents results where the activity
could not start due to a fatal error. The second represents results
where the activity did not start due to a non-fatal error. The last
range represents successful activity starts. Two convenience methods
have been added to ActivityManager to return whether the result
represents a fatal error and whether the result was successful.
Change-Id: Ifaf844c353641a28b03b3c2d7b6be053fd9b8b44
Fixes: 38021882
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
Fingerprint currently locks out for 30s after every 5 failed attempts.
This change makes it so that in addition to the above,
PIN/pattern/password will be required after 20 failed attempts.
Fixes: 35954316
Test: manual
Change-Id: I3aeb0e5b5b4d5011555f60fbe6cc2c1ce702a670
- Ensure that an activity that is auto-entering PiP when hitting Overview
does not show up in Overview. This is done by listening for the
onActivityPinned() callback from the system, and remove the pinned task.
- Ensure that we show the PiP task in Overview after it is dismissed, while
Overview is open. This is done by listening for the onActivityUnpinned()
callback from the system and refreshing the task list similar to when
the multi-window mode changes.
- When launching from a PiP activity, or launching back into Overview where
the next task should be PiP, then ensure that we scroll the stack to the
front so that the first task is fully visible.
- Fix two lingering Overview issues, when there are no handlers (ie. with
dynamically registered handlers), ensure that we call pre/post dispatch
callbacks (otherwise it could cause animated events not to work correctly).
Also, ensure that we don't update the dummy stack view TaskStack without
clearing the stack first, since we may be modifying the same stack
that the activity consumed when starting.
Bug: 34185886
Bug: 38207296
Test: Launch PIP activity from hitting Overview in the various ways
described above
Change-Id: I699e655106e6ed7206e163f9d3c15477bbfd52ef
Because we were relying on the output to go in the right direction
already, this could be wrong. We're now only following the given
lightness direction if it is even possible to satisfy contrast.
Test: runtest -x core/tests/coretests/src/android/app/NotificationTest.java
Change-Id: I06d934a6b5c328ebbf0cf707030b0d707ccb5ab4
Fixes: 38182819
