...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
...opening after selecting option "Youtube" as a luncher.
Also:
* Tweak window animations so that the wallpaper exist animations do not
stop too early (causing the wallpaper to suddenly disappear).
* Make sure no input is being processed while booting, to avoid
accidentally doing things especially in the upgrade dialog.
* Some other small cleanup.
Change-Id: I40a6b53731991d4e31ac4502e3d85f0e47507481
When the lockscreen is up we still enable the home and recent app buttons,
but the back button is only enabled if the lockscreen is not obscured by other activities
Fixes problem escaping from the DeskClock app when the screen is locked.
Bug: 5206013
Change-Id: I68c9e4513018f51e2ee4fc11254e42ecbef834e4
Signed-off-by: Mike Lockwood <lockwood@android.com>
When showing lockscreen, hide clock and navigation. Clean up logic
to be easier to understand.
Bug: 5112812
Change-Id: I20e3563aa36644db678c7839d47f01f223fe8d37
Bug: 5156144
Input channels could leak or simply live longer than they should
in some cases.
1. Monitor channels (used by the pointer location overlay) are never
unregistered, so they would leak.
Added code to handle failures in the receive callback by closing
the input channel.
2. The DragState held onto its input window and application handles
even after the input channel was disposed.
Added code to null these handles out when they are no longer needed.
3. Input channels previously used as input event targets would stick
around until the targets were cleared (usually on the next
event).
Added code to detect when the input dispatcher is in
an idle state and to proactively clear the targets then
to ensure that resources are released promptly.
4. Native input window handles held onto the input channel even
after the input window was removed from the input dispatcher.
Consequently, the input channel would not be disposed until
the input window handle itself was freed. Since the input
window handle is held from managed code, this meant that the
window's input channel could stick around until the next GC.
Refactored the input window handle to separate the properties
(info) and identify (handle) state into different objects.
Then modified the dispatcher to release the properties (info)
when no longer needed, including the input channel.
7. The pointer location overlay does not actually use its
standard input channel, only the monitor input channel.
Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to
request that they not be provided with an input channel
at all.
Improved some of the error handling logic to emit the status
code as part of the exception message.
Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
This integrates a new version of TransportControlView into LockScreen
and adds plumbing to handle new AudioService events to show/hide the view
and updates the required assets for all devices.
Updated to use new AudioManager API. Since the current API only supports
one RCD, the handler now lives in TransportControlView.
Change-Id: I220d4dd760bef35bd84209adc3c5829bf5bc9a2c
On devices that do not require showing lock before unlock, we now only create
just the unlock screen. In addition to simplifying the code, this also
prevents keeping around a potentially unusued lock screen and saves ~1MB
in the system process on devices with only a secure lockscreen.
Change-Id: I533f2692b44a7991d4850cecc874c76166e7ce71
Since LockScreen provides its own PIN entry keyboard, we don't need to show
the IME switcher button.
Change-Id: I04528acaee66e5109d631c0c79a3e7c64876e4c5
Change-Id: Iff2cfec5280a314989d915aa830c16124f921611
5214105: taking a screenshot while "Android is upgrading..." crashes device
5109947: Race condition between retrieving a content provider and updating its oom adj
1. The lock screen goes off after a certain timeout but a blind
user performing touch exploration of that screen needs more
time to find controls and interact with them. Therfore, we
reset the lock timeout by poking the wake lock on the last
hover event so the lock timeout will start ticking after
the user has stopped interacting with the lock screen.
bug:5133879
Change-Id: I340d2a820e90f6fd63a45d65a5457ce6e570189c
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
targetSdk < ICS
Compatibility support for existing apps. Apps in the wild that
properly target <=GB phones and HC tablets should be able to expect
that their small-screen UI will continue to work as intended on ICS
devices. Make sure that we show the soft menu button in the nav bar if
the current device was not officially supported in Honeycomb, the app
does not target ICS or newer, and the window does not have an action
bar.
Change-Id: I069c30841d3827a60ef8040831fde6f4c051d0ee
This introduces a new facility for code during the boot process
to display messages to the user through a progress dialog. This
is only for use when performing longer-than-usual post-upgrade
operations such as running dexopt on applications or upgrading
databases.
Change-Id: I0e78439ccec3850fb67872c22f235bf12a158dae
Prior to this change, we didn't have a mechanism to warn the user when
they were approaching the wipe data threshold dictated by active DPMs.
Here's the new flow:
- If a device policy manager is installed and sets the max
password attempts, we start warning the user when they are within
a grace period of hitting the max (currently hard-wired to 5).
- We continue to show a dialog after each continued attempt
until the user reaches 0 remaining attempts.
- We now show a message when they hit 0 so they know why their device is
being reset. The device will reboot and wipe data shortly after this final
dialog is shown.
Also increased the criteria for a pattern attempt from 3 dots to 4 dots
since the user can never set a pattern less than 4 in length. This will
greatly reduce the likelihood of a false wipe on the pattern unlock screens
without compromising security.
Change-Id: I28825ef21dfa2e2b6540e743252c6d50c41e5ad7
This adds an IME switcher button to lock screen. It is only
shown if the user has more than one applicable and enabled IME installed.
Change-Id: I5f9503a205c2edb27170825539ba4a6ef25418ed
