This fixes a bug where it was possible to authenticate the wrong user.
We now bind the userId when we start authentication and confirm it when
authentication completes.
Fixes bug 30744668
Change-Id: I346d92c301414ed81e11fa9c171584c7ae4341c2
When activity process is force-stopped (like in the case we need to stop
it to allow debugger), activity record is removed and a new instance is
added. Depending on timing, adding of new record could happen before
or after old record is removed. If it added after old record is removed,
then the removal could cause AM to also remove the task AND the stack
(if the activity is the last one).
On WM side however, the task/stack removal could be delayed due to
animation. So when AM attaches a new stack, we end up with two stacks
with the same stack id in the DisplayContent. Also, AM reuses the last
used taskId after it's deleted. So WM is confused and didn't add a new
task record. Then when the delayed stack removal fires everything is gone.
We need to use a different task id when creating a new task record, even
if the last created task is already deleted. Also when attaching a new
stack to WM, first check if we already have such a stack in DisplayContent,
if so, reattach it and don't create a duplicate.
bug: 30465601
Change-Id: Ic399a32c54f6acdcbb9a0c6155599331d55df232
In the case of no activity options we won't initialize
it again later, and so we will override the apps request
with a hint of 0 (ROTATION_ANIMATION_ROTATE).
Bug: 30683604
Change-Id: I5eed12adfbb241859503bcd40f15ee82141436d8
An accidental side-effect of introducing the XML content file and its
domain semantic checking was that the shared-storage domain got
dropped on the floor. Now the mechanism understands what it means
again.
Bug 29999884
Change-Id: I22b99c96869683d1a92430f237dda54b170b8f60
Smoothly unlocks device when going from a SHOW_WHEN_LOCKED activity
to a DISMISS_KEYGUARD activity while the device is trusted.
This change suppresses the jank from going briefly through the
lockscreen if the device is trusted and unlockable without entering
a credential.
Bug: 27410215
Change-Id: Idd86e825d37a89538a0a1f690daf6afcf94a0699
If someone calls removeActiveAdminLocked more than once, it is possible
for the device policy data to end up with more than one copy of an admin
in the list mRemovingAdmins. Due to extra entries, once the admin
component is removed, it is not being allowed to be set as an admin again,
until the device reboots or mRemovingAdmins is cleared from the memory
due to some other reason. Fixing this by making sure we do not add
duplicate entries to mRemovingAdmins
Bug: 30369197
Change-Id: I1d53c41312171425bbd6e6e4153148276f1b098d
- Adds a trusted signal from Keyguard to PhoneWindowManager
- Allows PhoneWindowManager to exempt DISMISS_KEYGUARD windows from force hiding
- Allows PhoneWindowManager to dismiss Keyguard while occluded
Bug: 27410215
Change-Id: I3ad490b64a5805b6f3888a9f37fcfbdd0116395e
We've seen some jitter in motion events with accessibility
enabled. We can eliminate it by not passing motion events
through the filter if we know they won't be affected.
Bug: 30183085
Change-Id: I0ecc8d5a39c8e370fc3a8ab85c6357251a31f8ad
We need to always update mLastFrame like we used to. Moving
the update inside the conditional caused it to not update on position
changes.
Bug: 30665565
Bug: 30641229
Change-Id: Ic71e8a8f91765870ebe2c0559f61aa83540c3a0d
