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
There are cases where lockscreen changes orientation (when docked, etc.),
but it's not easy to test. This allows lockscreen's behavior to be
overridden by command-line.
Change-Id: I7ce1e2ca0ea03a9034a6f537e33650e99e3594d8
- I am not sure under what circumstances mKeyguardView can be null in
onScreenTurnedOn() and I never saw this behavior before the commit,
but it can happen and prevent the device from booting
- Patched to fix line length
Change-Id: I39efa5c1d68158af5c108430036fe7c715ef855b
Prevent system overlays from showing above the notification bar.
Allow secure system overlays to be fullscreen, for the pointer
location view.
Show the drag layer above the notification bar.
Change-Id: Ic8d663792a243cca2cd9952d241d001e0357d551
Touching StatusBar.disable() directly can make the cached value over
in StatusBarManagerService stale. Instead, dispatch DISABLE_BACK
through setSystemUiVisibility() on tablets; it's unused on phones.
Also DISABLE_NOTIFICATION_TICKER when showing secure lockscreen, and
watch for TIME_CHANGED in DateView.
Bug: 5255469
Bug: 5242677
Change-Id: I4efaf9799b2f229f49d7024da5dafceacd5e08bb
Make sure that options menu panel presenters associated with a PhoneWindow
get re-wired properly when a new menu is generated.
Change-Id: Ic06130019aec8b8edc372054c348f147d164fc5f
In the past we were overly cautious about not recreating the lockscreen
under steady state conditions. However, that allowed lockscreen
to get into weird states where the screen orientation and the
loaded layout disagree. Once in this state, the user could not
recover because we would never reload the layout due to the fixed
orientation of lock screen.
This avoids the problem by being more aggressive about reloading
the layout. It now recreates the lockscreen (for reals) whenever
a view requests it via recreateMe().
In addition it serializes recreateMe() requests to ensure a pending
configuration change event has a chance to propagate and be handled
by the lockscreen looper.
Change-Id: I86a54abba899eb314f7cc8dbf6cbb98266bc548a
Persistent process can no longer use hardware acclerated drawing
when running on a low-memory device.
Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
Keep track of lockscreen clock visibility, and only hide statusbar
clock when one is provided by lockscreen. This fixes bug where widget
would hide all clocks.
Bug: 5242065
Change-Id: I48de98ecb956c7f22bd40b54d771c78c1a80c14c
