Add new option to startActivityAsCaller() which allows you to
specify that we should not do security checks on the target
activity being launched.
Change-Id: Ie6b28807b96fef35ccdff93b0a01066cfd8fa307
This is in preparation for enforcing the minimum length of MACs
which in the case of HMAC keys generated or imported by Android
Keystore will be set to the length of the digest for which the
key is authorized.
Bug: 22337277
Change-Id: I0255d5ba184dabfb6b45d8f32ddadeb84ab7fc19
It is possible for an app token to be marked as hidden and exiting
because the previous activity destory is completed before we are
good-to-go with app transition since we are still waiting for the
opening app to be done drawing. In this case we don't apply the
exiting animation since the token is not changing visibility state
during the app transition (it is already hidden and we are telling
it to hide...).
We now allow the animation to load if the token is already hidden
and marked as exiting.
Bug: 22381703
Change-Id: I5c27b6c3c1f810f05b2d716122055c6f12d0a167
Applications installed for a specific user must be verfied as that user. However,
apps that are installed globally [i.e. UserHandle.ALL] should not be verified by
every user on the device. Instead, they should be verified by the device owner.
Bug: 21901423
Change-Id: I5fd3f690d08e7e911a3c86f09bbfcd4eb635b418
Bug: 22444755
WindowManager may decide to yank the surface at any point, so
attempt to kinda handle this
Change-Id: Id2f665d2f0f93bccd4ec977fbf52dca4dc1ec891
Bug 22505481
ag/684544 added a feature to allow shared elements that weren't
shared into an Activity to be shared back. However, if you are
targeting an older version of the SDK, you may get an unexpected
shared element back. This change in behavior has been locked
behind a target version check.
Change-Id: I7162e24f3b14fedd6b308e89e9d04ac67660f7d6
To qualify for cross-profile app linking, an intent should resolve
with a better status than "NEVER". Moved this check from canForwardTo
into the source method, getCrossProfileDomainPreferredLpr, to stop
bad resolutions leaking out.
BUG:22287521
Change-Id: I195979d78a783864d841a81f358780912bbf168e
This CL addresses TODOs in Ib641dda49f7ab1c7d60207c36a47767bb408.
With this CL the position of PopupWindow is always specified in
window-local coordinates even if FloatingToolbar#mParent is not a
decor view.
Bug: 22335001
Change-Id: I0cdd63a00051fa30981e517c07682075467ac598
This is a coment-only follow up CL for I71a8d356e868dc7715b030ca,
which wrongly changed coordinates from window-local to view-local
(relative to FloatingToolbar#mParent) when showing PopupWindow.
The position of PopupWindow still needs to be specified in
window-local coordinates as we had done before
I71a8d356e868dc7715b030ca1078da4ec39368c3.
Currently the problem might not be visible to users because
1. FloatingToolbar is not a public API hence all the instances
are under our controll.
2. FloatingToolbar#mParent is alwasy initialized with
PhoneWindow#getDecorView() for now.
Bug: 22335001
Change-Id: Ib641dda49f7ab1c7d60207c36a47767bb408971c
This fixes a bug where the framework was sending repeat cancel
events in response to terminal status (onAuthenticated(), onError())
which causes the underlying HAL implementation to get into a weird state.
Now, only client-initiated events like an explicit cancellation
or starting another authentication/enrollment invokes fingerprintd's
cancel() method.
Fixes bug 22438498
Change-Id: I762bab1c8635924848f9f4334db47a07130d5ae3
