Previously it was possible to get an inconsistent state because there
were two paths that updated the lock screen sim state. This reworks
the data flow to ensure the same path is always used to update the state.
KeyguardUpdateMonitor now correctly updates the entire state of the callee
whenever a new callback is registered.
In addition, KeyguardUpdateMonitor now caches the phone state in order
to avoid a round-trip binder call in updateEmergencyCallButtonState().
This avoids a condition that could make lockscreen unresponsive while
updating the emergency call button state.
KeyguardStatusViewManager also ensures the TransportControlView is
hidden when created to ensure we don't inappropriately update the carrier
line while waiting for the first callbacks to update the status lines.
Change-Id: I6b3975b703a7d90bac8d0fe29fbc0f1d9c5e0e7d
Bug: 4981385
Changed the orientation listener to notify the policy whenever
its proposed orientation changes, and changes the window manager
to notify the orientation listener when the actual orientation
changes. This allows us to better handle the case where the
policy has rejected a given proposal at one time (because the
current application forced orientation) but might choose
to accept the same proposal at another time.
It's important that the proposal always be up to date. A proposal
becomes irrelevant as soon as the phone posture changes such
that we can no longer determine the orientation with confidence
(such as when a device is placed flat on a table).
Simplified the orientation filtering. Now we just wait 200ms
for the device to be still before issuing a proposal. The idea
is that if the device is moving around a lot, we assume that
the device is being picked up or put down or otherwise in
the process of being moved. We don't want to change the rotation
until that's all settled down. However, we do want to tolerate
a certain amount of environmental noise.
(The previous confidence algorithm was also designed along
these lines but it was less direct about waiting for things
to settle. Instead it simply made orientation changes take
longer than usual while unsettled, but the extra delay was often
too much or too little. This one should be easier to tune.)
Change-Id: I09e6befea1f0994b6b15d424f3182859c0d9a530
change
Let action bars move between split/unsplit mode on configuration
changes if set to split when narrow.
Change-Id: I13f5115a65247cb1878ee823493ca8e2b6ba4cf6
...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
After pressing forgot pattern and entering credentials, it used to
bring you to the screen to choose a new pattern. Now you are brought
to the screen to choose any unlock method. The reason for this change
is that both Pattern and FaceLock are valid possibilities when a
pattern is forgotten since FaceLock can use a pattern as a backup
method.
Change-Id: Ide28a780771a50952e72c3c06e1f71cbcb48f834
Theme.Holo.Light.DarkActionBar gets black text
Make sure that menus generated for use in action bars get themed correctly.
Change-Id: I14ba676d296c785514425d40d89e62dc4ff1da1a
Be more explicit about initialization -- power manager never sends
screen update when first initializing, phone window manager retreives
current screen state and applies that itself when initializing.
Change-Id: I8294ed36d700e186c1637754df8c8183721c15dd
1. Make Pin and Puk focusable EditText.
2. Add hint text for pin and puk.
3. Update focusEntry logic.
bug:5243771
Change-Id: I65bd52510bbbf0ebd7830ecac7e31159ae750c6c
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
ActionProviders (or action views) unfortunately had no way to report
that they had opened a sub-UI that would affect menu visibility
listeners used to hide action bars when not in use. This caused the
Gallery UI to hide its action bar when the share popup was open.
Add hidden API (to be made public later) to ActionProvider that can be
used to inform the menu system that a sub UI has opened or
closed. Account for this in menu visibility callbacks. Fix
ShareActionProvider to use this when its popup windows open and close.
Fix a regression where submenus were not properly reporting visibility
changes.
Change-Id: Ia6f45fb463ad106105c40d01f141c2e5c8b96f78
Notify the register the current sim state right away in
registerSimStateCallback.Otherwise the register won't
receive any state until sim state gets changed again.
That will introduce a racing condition. If the sim state
changes to PUK_LOCKED after registering the callback, the
PUK unlock screen shows up. If the sim state changes to
PUK_LOCKED before registering, the PUK unlock screen won't
show.
bug:5243771
Change-Id: I27de1329a30adba68952cf086d2130c4cef54270
We need to hold a wakelock while playing the keyguard lock sound,
so that it actually completes before the CPU goes to sleep.
Change-Id: I144c345383afeb911ea461b2eb17b31183b6d092
The key thing was to fix isVisibleOrBehindKeyguardLw() so that it
wouldn't count a window as not visible if it was just currently
in the process of drawing due to an orientation change.
Also improve logic in deciding when to turn screen on to better ensure
the screen is in a stable state, in particular treating screen off
as a frozen screen and not allowing it to turn on until the
update of the screen due to any config change is done.
Change-Id: If82199f3773270b2d07f9c7de9da2dad8c7b28d7
Change the standalone action mode window for overlay mode to be of
TYPE_APPLICATION. (This also fixes a bug where overflow menus would
not work properly on these types of action mode bars.)
Set exitFadeDuration on btn_cab_done_holo_* drawables.
Remove no-window-focus override selector states for selectable item
backgrounds to allow proper touch feedback on windows that do not have
focus but that the user can interact with.
Change-Id: Ib504866238708150d21e6183ff7b695869c05d3e
Rework how we decide when it is okay to turn on the screen by having
the policy call back to the power manager when it knows the lock screen
has been drawn.
Change-Id: Ie8f3f72111dcf7f168723e6dce24e0343b4afe5d
- FaceLock area now specified in layout files instead of trying to
grab an existing view, which was only practical if pattern was
backup method
- Now fills area it is supposed to and works with pin as well as
pattern backup
- Backup method is no longer exposed behind FaceLock just before it
starts or just after it tells the lockscreen to unlock
- Added synchronized blocks so FaceLock cannot be told to stopUI by
two different threads at the same time
Change-Id: I3bfad6b44dbe0e3c2ea3c87d2978451c22a7484c
...mode cuts off screen rendering
The code for limiting application window sizes to not include the
navigation bar was dead. Now it is back.
Change-Id: Ic0bde56e3300fd0d9d225e19d8de2766d07e8780
PhoneWindowManager now takes full responsibility for deciding where the
navigation bar goes. This gets rid of a bunch of race conditions with
determining layout while the nav bar is moving itself at the same time
the window manager is computing a new configuration.
Note that this breaks the "nav bar on left" option. The current nav
bar code could also be cleaned up some more to completely drive its
behavior based on onSizeChanged() happening during relayout.
Change-Id: I1651d74c3464ba0d588aab3049e099c78420146a
action mode is turned on/off
Fire AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED when action modes
come and go to give an indication of UI change on the level of a menu
or dialog opening/closing.
Change-Id: Id36c6153b0722b4b6927c8d36503e8ac57c2d2b2
Bug: 5299191
Bug: 5300282
Only send keys when mCode != 0.
Simplified the logic for repeating / non-repeating keys.
Key down / up are always correlated with touch down / up, the
only thing that's special is that we detect long press for
repeating keys and not for others.
Ensure that up or cancel is always sent for every key
that is generated. Previously it was possible for keys to get
stuck down if touch moved out of the button's active area.
Removed the funky HOME long press timer. We don't need it
since we can rely on the long-press flag instead. Since the
system UI is in direct control of key repeating and long-press
behavior for the keys it inject, this eliminates the need for
special hacks to circumvent the timer.
Ensure that the same haptic feedback is provided for all keys,
including the recent apps key. Previously this only worked
because the code was injecting a bogus key with code 0.
Don't generate repeated haptic feedback for virtual keys
even when those keys are injected. This doesn't happen
for virtual keys synthesized by the InputReader because it
never injects repeats itself (the InputDispatcher synthesizes
them), but it is an issue for the KeyButtonView.
Change-Id: I8b3615dde738af28e76898d161d6ce9a883b59ec
When facelock is enabled, isPasswordEnabled or isPatternEnabled will return true depending
on which one is set as the backup method. This is a cleaner way to handle things, rather than
specific cases for facelock in all the methods that call these functions.
Change-Id: Iacb802b89626dfc13f2306de1a2e622ca9b69427
