am: 35bdda107f
* commit '35bdda107fe76ab62087527946b201551ddfe965':
Animate backlight quickly when display state request to change or power mode changed
Make sure NaturalSurfaceLayout is consistent with SurfaceControl
This case could happen in real world if a non-resizeable activity opens
another activity (eg. Messenger app opens an activity to write up the
message). Need to make sure the new activity is not resized.
Change-Id: I222985fa7ee2cbd94c843ac1190239cce31d3c0c
Keyboard shortcuts are requested via WindowManager, and
the request pipes through to the view root and the window
callback.
Bug: 22405482
Change-Id: Ic0071e91c7b554be3ac9df71e9539ee8a60e822e
Scrolls to the RemoteInputView when it's beneath the IME.
Also fixes ViewRootImpl to take into account translation
when calculating the location of the focused rect.
Bug: 22452379
Change-Id: I9b9649edeabf9bcab8fc487fe92dec62f388737e
Cancel() has apparently never worked. Calling cancel() results
in the startTime being set to Long.MIN_VALUE. In theory, this means that
on the next animation frame (getTransformation()), the elapsed time
(currentTime - startTime) should result in a large positive number, which
is way more than needed to prove that the elapsed fraction is >1 and
therefore that the animation has ended. But in practice, anything subtracting
MIN_VALUE will result in a large negative number due to Long wraparound, so the
end check fails and the animation continues. Forever.
Moreover, event fixing the cancel issue results in a repeating animation
continuing to repeat, because the logic was never there to determine whether
a repeating animation was canceled.
This fix addresses both issues, but in a minimal way. The risk in fixing this
for real is changing the behavior of cancel in a way that existing apps would not
expect. For example, it's weird that cancel causes one more frame to run. And even weirder
that it does so with a negative elapsed duration (resulting in an animation fraction of 0).
But I wouldn't want to change that behavior for fear that I'd break apps who rely on
that weird behavior.
Instead, there's a simple check for for the "expired" check and the "repeat?" check that
sees whether the startTime has the magic value of MIN_VALUE, which should only happen
when an animation has been canceled. If this is the case, it ensures that the animation ends.
For real.
Issue #24984018 canceled animation runs forever
Change-Id: Ia137eb04bd7df3976a4d9cef86fd39a78dc56f39
A poorly placed clear identity was causing some crashes as
apps were required to have the MANAGE_USERS permission to
query if the current user is secured.
Change-Id: I1120b1e4405e78389fcbcb3e7d1dba8c80500da3
For split-user cases it has been identified that provisioning
a profile-owner during user setup-wizard shouldn't cause
the setup-wizard to exit early generally. Adding this extra
allows a DPC to control whether the user can take further steps
in the setup-wizard after management provisioning completes.
Adding as a hidden extra since we don't expect this to be useful
until after N release.
Bug: 25858670
Change-Id: I599a5df4aef659769a6323402efe078d0d12d2ed
Change the current static condition to a per-user condition so we
can check and enable/disable the work challenge properly. Also add
an isAllowed API, as the Work Challenge can only be used when the
user's DPC targets N or above to maintain backwards compatibility.
Change-Id: I0cb8b475838816801868ffb24726407aa257b4de
PhoneWindowManager.interceptKeyBeforeQueuing isn't good place
to handle long press because rejecting a down event will not
synthesize further key repeat.
Move the logic to PhoneWindowManager.interceptKeyBeforeDispatching
instead.
This is the regression caused by following CL
001c59c Route volume keys directly to the audio system on TVs
Bug: 26268032
Change-Id: Ic8f6dfaec473c0d45ffa42475763622dc700e635
