This was a bug only when the status bar was hidden, the screen space for
the nav bar would not be correctly removed for all frames used in layout
computation.
This code really $*#&^!! needs to be cleaned up, the whole "status bar
is the system bar when on a tablet so it should take space from apps,
but status bar doesn't do that on phones but on phones there is a nav
bar that does the same thing" thing is whacked.
Proof that evolution DOESN'T WORK!!!!!!!!!!
Change-Id: I24e4994328480820cb638e7a40aa0b65b7ae2003
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
This fix does not include the change to ignore app tokens that are
hidden. This causes problems in some dialogs that stay hidden until
their app is ready to display, but need to perform a series of relayouts
during that time to get to the right size. Dropping this part of
the change still (mostly?) seems to allow us to avoid the bad states.
Change-Id: Ic052cb1499d3287f47e9ffeac5cd2470ee5a308c
This fixes a bug where the device fails to lock when DevicePolicyManagerService
requests the device to be locked and the screen was off because the user hit
the power button.
The change allows DPMS to directly invoke screen lock, bypasssing the screen state.
Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
Also don't consider windows a candidate for layout if their app token
is hidden. This fixes a transient state where we are preparing to
unhide the window but have not done so yet.
Change-Id: Ife5299ffa003c1df1a4f787b7a2809cbf614ec16
This fixes a bug introduced in testing 34a62348. The code now
properly invokes the callbacks before returning.
Change-Id: I637a8a792838379f0c8b42ef634da82787fcd961
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
- cherry-picking framework CLs from master into ics-mr1 that are
needed for FU to work on tablets
- needed for OEM partners even FU isn't going on xoom
Squashed commit of the following:
commit 3258f2528f558efdaf34ae15c5425f2d879848fe
Author: Brian Colonna <bcolonna@google.com>
Date: Tue Dec 13 15:49:48 2011 -0500
Added Face Unlock to tablet lockscreen layouts
The Face Unlock Area was not part of the tablet layouts, so prior to
this change, Face Unlock would not show up on tablets when selected as
the unlock method. The backup unlock method would show up instead.
The goal here is for the pattern and PIN unlock layouts (in both
portrait and landscape mode) to look the same as before this change.
This was a little harder than it was with the phone layouts for two
reasons:
1) For the phones it was ok for Face Unlock to be sized such that it
just covers the backup method. For the tablets we want Face Unlock
to cover far more real estate.
2) The phones were based on a grid layout, whereas the tablet is a
linear layout.
Note that the diff makes the modifications look way more extensive
than they actually are. Basically, in most cases I am putting a
relative layout around some existing portion of the layout and
putting the Face Unlock Area area inside of the new relative layout.
Change-Id: I478becddf2a9ee9fe7b6d653e604fa3ad89b822f
commit 821cfe85cf2b3daf074d9749dbf6e0a5663af0de
Author: Brian Colonna <bcolonna@google.com>
Date: Mon Dec 19 15:51:10 2011 -0500
Unbinding from FU when going to backup
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
commit fa90bb76ac6b311d12b55d23df4ac44cec62c7b3
Author: Brian Colonna <bcolonna@google.com>
Date: Mon Dec 12 18:02:23 2011 -0500
Changed how Face Unlock coordinates are specified
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
Change-Id: I962c0486be85949e002b0a2701286a6a39251f36
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: Icc9f674299f8dbe2b736a5622a4965904d27e49c
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
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
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
- Remove silent mode from Power menu
- Show volume dialog on lockscreen
- Allow beeps when adjusting volume in lockscreen
Bug: 5586083
Change-Id: I93052a8ec5004c784f20e04488af9382d495e711
