This adds a feature to delay locking the device when the power button
is pressed. This fixes a use case where the user wants to turn off
the display (e.g. to save power) but doesn't want to lock the device.
For the case of a secure device (user has a pin/password/pattern),
this will lock the device immediately or not based on the setting.
For the non-secure case, this always "locks" the device to provide easy
access to the camera while preventing unwanted input.
Change-Id: Ie328485c3f7559e26896d761cbf0e69d3f4df4e2
Lockscreen was stopping Face Unlock when going to the backup lock, but
not unbinding from the Face Unlock service until the device was
unlocked.
This caused a bug on the tablets where Face Unlock would reappear when
switching between portait and landscape orientations, even after the
backup lock was exposed. On an orientation change, Face Unlock is
restarted if the service is bound to during the orientation change.
Since it was bound to when it should not have been, Face Unlock was
restarting when it should not have been.
The wakelock is also now being poked on an orientation change because
on the tablet you can keep Face Unlock alive by switching the
orientation back and forth, but eventually the screen would go dark
with Face Unlock running.
Also, a conditional was moved in activateFaceLockIfAble() so the whole
section isn't executed if Face Unlock is not in use. Part of it was
being executed with only the inner-most part having the check. This
did not cause any issues that I am aware of.
Change-Id: Ib452b8ced28a507bf9272dbf5d3477a8abd1ba90
The idea is that this is a device which is more-or-less headless. It
might have some limited interaction capabilities, but it's not something
that you want to rely on having.
Change-Id: Ib92f53a120bf83de781728011721a4859def7d9f
Show "emergency call only" text in carrier string
only if phone supports emergency calls.
bug:5570742
Change-Id: Ie826583fd55073e57c5fe4fe6e585781127caa6a
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
Was using View.getLeft() and View.getTop() to specify the upper-left
corner of the Face Unlock area. That gives coordinates relative the
view, which was fine for the phones. For the tablet it needs
coordinates relative to the window (which still works for the phones).
Also fixed a 'bug' where h and w were swapped. However, it wasn't
causing a problem because it was swapped in two places.
Change-Id: I86c1f68439f1dcef826cfe6b8fb56c9a4a6b8dc3
Fixed a problem where the key up for the ALT or META key was not
delivered to the task switcher dialog because it was deemed
to be inconsistent with the window's observed state. Consequently
the dialog would not be dismissed when the key was released.
Moved global hotkey handling for META+* shortcuts and ALT/META-TAB
into the window manager policy's interceptKeyBeforeDispatching
method. This change prevents applications from hijacking these
keys.
The original idea was that these shortcuts would be handled only
if the application did not handle them itself. That way certain
applications, such as remote desktop tools, could deliberately
override some of these less important system shortcuts.
Unfortunately, that does make the behavior inconsistent across
applications. What's more, bugs in the onKeyDown handler of
applications can cause the shortcuts to not work at all, for
no good reason.
Perhaps we can add an opt-in feature later to enable specific
applications to repurpose these keys when it makes sense.
Bug: 5720358
Change-Id: I22bf17606d12dbea6549c60d20763e6608576cf7
Bug: 5721663
Added content descriptions and made the listview allow navigation between nested
views.
Change-Id: I69d78d65e1bab829f63c2e6025051206e511f00f
3-state item to toggle between Silent/Vibrate/Ringer in long-press power menu.
No volume dialog on lockscreen, unless Power menu is up.
Set VIBRATE_IN_SILENT=1 when upgrading device.
Change-Id: I097d216f96c4abdbd83420e0c477106951b3607d
It appears that https://android-git.corp.google.com/g/#/c/144795/1
was incorrectly merged down into master. This commit is to correctly
add the change from that cl into the master branch.
Without this change, if you bring up the emergency dialer while Face
Unlock is running, you momentarily see the backup lock.
Change-Id: I6350150bf46ac52d5c50c9e88119f09397d22902
New API to let you build an Intent whose base configuration is correct,
but has an additional "selector" to pick out the specific app that you
would like launched.
Change-Id: Ide9db6dc60e2844b7696cfe09b28337fe7dd63db
This change simplifies the code associated with receiving input
events from input channels and makes it more robust. It also
does a better job of ensuring that input events are properly
recycled (sometimes we dropped them on the floor).
This change also adds a sequence number to all events, which is
handy for determining whether we are looking at the same event or a
new one, particularly when events are recycled.
Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
- Remove silent mode from Power menu
- Show volume dialog on lockscreen
- Allow beeps when adjusting volume in lockscreen
Bug: 5586083
Change-Id: I93052a8ec5004c784f20e04488af9382d495e711
As it turns out, it used to be possible for there to be multiple
input events simultaneously in flight in an application. Although
it worked, it made it hard to reason about what was going on.
The problem was somewhat exacerbated by the introduction of a
queue of "InputEventMessage" objects as part of an earlier latency
optimization.
This change restores order from chaos and greatly simplifies the
invariants related to input event dispatch within the application.
Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
5433192: Factory reset device: compatibility screen is the first...
...screen before setup wizard
Don't show compat mode dialog if compat mode is unknown (which happens
early in boot before an activity is shown for example). Also make sure
to update status any time the current focus app token changes, so we
correctly update every time switching apps.
5651152 [Stingray] change zoom/strech setting icon won't go away
This is probably also fixed by updating when the app token changes.
Change-Id: Ibe9bd6277166230d5d96689741b78325ea099d57
Don't disable volume slider when it hits zero.
Show correct icon for Silent mode in Power menu.
Bug: 5586083
Change-Id: Iaa957fc08e314e0de1c007dfc967a1d960080aab
