Also make sure that the bounds passed to stacks and tasks are not bogus,
as these would mess up the configuration.
Bug: 26512887
Change-Id: I1a3a9c867a2c258a326b31df2bac614ccbb00579
am: 099bd9ca8f
* commit '099bd9ca8fea02795424d62c05c723290d68ae14':
In CanvasContext::doFrame, make a separate call to computeFrameTimeNanos and save the result. Then pass that value to UiFrameInfoBuilder::setVsync as both arguments.
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
