1. The accessibility events for switching a widget were dispatched
before we update the important for accessibility property. We
were lucky to get events in some cases since the pages in the
pager had alpha grater than zero, i.e. the page was already
set as important for accessibility, due to a running animation.
2. Accessibility focus clear event not fired if we give focus to
another view. The old focus was correctly cleared just the
events were not dispatched.
bug:8599670
Change-Id: Ia2647d77eaa4e10fbaf3a047dc9ea5b728f9c3c3
While it's still not generally appropriate for the home key
to do anything other than take you home, a car is a somewhat
different context: because of the user's reduced ability to
interact with the device, it's especially useful to
temporarily replace the launcher with a car-optimized
variant. While it would be ideal for the entire system
(particularly the user's everyday Launcher) to dynamically
reconfigure their UIs upon entering car mode, it's not the
case today, and car home apps are a useful compromise.
Quick test:
$ adb shell am broadcast \
-a android.intent.action.DOCK_EVENT \
--ei android.intent.extra.DOCK_STATE 2
This reverts commit 7c135205f2f4c192299ad0215276e9e481bccaa5.
Bug: 8234767
Change-Id: I17588fff46e7f5e3773d3ad202601a5642943444
If the hardware composer HAL does not provide full support for
multiple displays, it may be necessary to force the HDMI rotation
when not docked. (When docked, we can use the dock's orientation.)
This configuration is not expected to be used on newer devices
with the requisite HAL support and may be removed in the future.
Bug: 8511721
Change-Id: I1ff50f00ee7fe621aceff94bd938ecf6385c3f38
We had been intentionally disabling FUL when switching to a new user.
The reason was that we were only getting a signal when the user switch
started, not when it completed. If we started FUL at the beginning of
the user switch, it could be completed by the time the user switch
completed. We now have a signal to tell us that the switch completed.
Prior to this change, FUL would start whenever keyguard is created.
For a user switch, keyguard is recreated when we get
onUserSwitching(), but we don't want FUL to start until we get
onUserSwitchComplete(). So with this change, if onResume() happens
because of a user switch it doesn't start FUL until we get
onUserSwitchComplete().
Change-Id: I1d3da0a32b9b4cf0cfa5c577f1697d2a41ee4fda
Otherwise, setting both FLAG_DISMISS_KEYGUARD + FLAG_FULLSCREEN
will hide the status bar (by not forcing it) when the secure
keyguard is showing.
Bug:8567697
Change-Id: I441d9c1bc0e106672b6d29427d291f41eaf1e697
...to allow for orientation locking
This doesn't add an API to get the current orientation, since that is
inherantly racy. Instead there is a new "locked" orientation mode that
locks the screen into whatever the current rotation is.
While at it, added a few other useful orientation modes.
Change-Id: I5c369e6511cb72294e9e922ea8acffd770df9440
This fixes a bug where the clock sometimes doesn't show due to the
alpha values not being reset when the widget page order changes
due to removing a widget.
Fixes bug 8545025.
Change-Id: I17c531af4c844647b3262fcf56faa84fff8bafc5
This fixes a bug caused by not keeping track of previous play
state properly in keyguard as well as showing the transport
even when in STATE_INVISIBLE.
Fixes bug 8473575
Change-Id: I28bd382c53645a7c44541b3139c0a60569865219
Fixes the KEYCODE_HOME case, awakes when home is
started for any reason.
Also awaken when toggling recents (and not locked).
Bug:8557212
Change-Id: I6578ae3971740a03c27596b838d27a5ab9b03752
Some apps aren't particularly happy if a stray key event is dispatched
to a newly created window before its menu is prepared, causing the
action bar's Home/Up event to be dispatched. Ignore these clicks on
the Home/Up button before the menu goes through its initial prepare
step.
Note that it is still possible (and valid!) for Home/Up to be
dispatched even if the app chose to return false from
onCreateOptionsMenu or similar.
Bug 7085070
Change-Id: If4b7d5f8c5a08ce8a094f1919347604d78ddedfb
Add global key configuration file. A global key is one that is handled by
PhoneWindowManager before dispatching and sent to a given component via
broadcast instead of going to the foreground app.
Bug: 8510681
Change-Id: Ic6a8e559680d005613ed22874b27eb78bbfc4499
RemoteControlClient defines two listener interfaces for playback
position, one to let the framework query the current playback
position, the other to request playback to seek to a given
position.
Updated IRemoteControlDisplay interface to support passing info
about whether the user of RemoteControlClient can provide a
playback position, and receive a new one.
Updated implementations of IRemoteControlDisplay to new
interface.
Bug 8120740
Change-Id: I1a5a969da4d0f8c9ad27f691919dd08f8653982b
When a tablet rotates, FUL must be stopped and restarted in a new
position. 90 degree rotations cause a configuration change, causing
FUL to be automatically reconstructed in the new location. However,
a 180 degree rotation is not a configuration change, so FUL was not
restarting. A 180 degree rotation happens more often than one might
think. If you set the tablet down and later picked it up in the
opposite orientation, FUL would not work prior to this fix.
This change adds a rotation watcher to KeyguardFaceUnlockView. It
watches for 180 degree rotations and stops and restarts FUL
accordingly.
The rotation watcher callback must be unregistered when
KeyguardFaceUnlockView is recreated (as during 90 degree rotation
changes), otherwise the number of rotation watcher callbacks will keep
growing and they will never go away. This is a problem not just
because there are many callbacks hanging around, but also because the
old callbacks end up trying to access biometric unlock views that no
longer exist, resulting in crashes. So, a simple function was added
to the window manager to unregister a rotation watcher.
Change-Id: Ie1ef20a9a22b8f4e39918987dff2b8ad444fcfd1
Extend RemoteControlClient class to support reporting the
current playback position, and the playback speed.
Define listener for an application to receive new playback
position to seek to (use of listener to be implemented).
Update IRemoteControlDisplay implementations to new interface.
bug 8120740
Change-Id: I2654daeca1ac49713d325df8226dceb85943c020
As options menu invalidations in PhoneWindow are deferred, it was
possible for a call to open the overflow menu (which involves an extra
chance to prepare the menu) to happen before the pending menu
invalidation was handled. Process any pending menu invalidations
before attempting to show the overflow menu in response to one of
these events.
Bug 7209308
Change-Id: Id50f7f6ad5d3a631745207fa0bad8c356690e16c
Add a boolean configuration option config_useFixedVolume indicating if
stream volumes or master volume can be modified.
If the option is true, the AudioManager volume and mute APIs will be no ops and the
volumes will be maxed out.
To be consistent:
- the ringer mode is forced to normal and cannot be modified
- volume panel is never displayed
- volume settings are not available
- ringer mode global action is not displayed.
The default for this option if false.
This is useful for a class of devices intended for connection to a digital
audio output only, where the volume is directly controlled on the audio sink.
Bug 8161458
Change-Id: I2571d5ee79952ef0914d8fd1985816467a80adcd
The emergency call button area overlaps the carrier text area,
which is only noticeable when pressed/highlighted.
Smoothly hide the carrier text when the emergency call button is
pressed.
Bug:8424348
Change-Id: I78ba97739d58cc7f974e36dca81cfcd42703d3fe
Now that we can have multiple IRemoteControlDisplays, create a
persistent one in KeyguardUpdateMonitor so we can more efficiently
show and hide the music controls in keyguard.
Update after review: get the current state from KeyguardUpdateMonitor
*before* the first call to showApprpriateWidgetPage(). This fixes
a flash that was sometimes seen when transitioning between orientations.
Fixes bug 7517659
Change-Id: I1b7b6f4222a99891ec06d6b6fd779dd0b86cc367
Otherwise hitting "Forgot Pattern" traps you in account mode.
Avoid the known case where account is not backup (if permanently
locked).
Bug: 8381295
Change-Id: Ifda28eec6d0609e822b210831ff0ea0ec6cb22b1
This fixes a bug where keyguard was created without setting
the preferred orientation. The result is it would temporarily
assume the orientation of the device after being hidden.
The fix sets the flag when the keyguard view hierarchy is created
rather than when visibility changes.
Fixes bug 8124979
Change-Id: Ic54a185e4f51f79f2bb7fbc5ffc6992641e89132
Update the album art bitmap size to the sent to the IRemoteControlDisplay of
Keyguard on layout size changes.
Change-Id: I178eba8cbff3d4ffb5232318469c43d95da2f11f
Switch the action bar to always use the overlay layout, and
make it smarter to do the right thing depending on whether the
action bar is in overlay mode or not.
This allows apps to use the system UI magic flags without
having to worry about whether the action bar is configured
in overlay mode or note -- just select a stable layout and it
will automatically go into overlay mode.
In the future this should also allow us to simplify the action
bar code, since it is all sitting on one common implementation.
For example, much of the logic in ActionBarImpl can be moved
to the root action bar layout, and that layout can be optimized
to do custom layout with all of the known elements it has.
Also fixed a little bug in the performance tests.
Change-Id: Iec0c0c0699754f0d1ce37402d786b4966e052a56
The window manager now maintains and reports a new formal
"overscan insets" for each window, much like the existing
content and visible insets. This is used to correctly
position the various UI elements in the various combination
of layout options. In particular, this allows us to have
an activity that is using fitSystemWindows to have the content
of its UI extend out to the visible content part of the screen
while still positioning its fixed UI elements inside the
standard content rect (and the entire window extending all
the way into the overscan area to fill the screen as desired).
Okay, maybe that is not written so clearly. Well, it made
my head hurt too, so suffer!
The key thing is that windows now need to know about three
rectangles: the overall rectangle of the window, the rectangle
inside of the overscan area, and the rectangle inside of the
content area. The FLAG_LAYOUT_IN_OVERSCAN option controls
whether the second rectangle is pushed out to fill the entire
overscan area.
Also did some improvements to debug dumping in the window
manager.
Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
Allow fullscreen windows to specify crossfade or jumpcut animations
that override the default rotation animation. Only if the incoming
and outgoing topmost windows are fullscreen and both specify the
same animation to use.
Fixes bug 8182773.
Change-Id: I6b3c0020d7bd2cdfba5c66189e114ec62cd54fcf
Keyguard currently relies on being in the system process to grab the
given user's widgets. When we split keyguard into a new process,
it will need to have access to user-specific info to instantiate a
specific user's widgets. In order to accomplish this, we add an
explicit userid to each binder call as well as new permission
check to allow keyguard access.
This also fixes a potential race condition of having an incorrect user id
due to an async call to change the user. Every binder call now has a specific
user id. The user id is either the calling process user's id or an explicit
one passed by applications like keyguard. It is created once when an
AppWidgetManager is instantiated and remains for the lifetime of the object.
Fixed bug where widgets sometimes didn't show up for secondary users.
Moved permission check in AppWidgetService into getImplForUser()
Refactored to use userid from context associated AppWidgetManager instance.
Clean up AppWidgetHost to use userId from Context.
Remove redundant userId check in checkPermission since it's handled by
ActivityManager.handleIncomingUser()
Removed redundant userid check.
Upload after rebase...
Change-Id: Iae3e20f2b342c323bb58768b3d22051510f8268b
Introduce another new rectangle in window layout, the
restricted overscan region. This is for windows that can
be in the restricted region (that is, full screen but with
hard restrictions like the nav bar) but whose content can
be adjusted for the overscan constraints.
In other words, normal application windows now always extend
into the overscan region, and we push their content inside
of it.
Change-Id: Ibccf3d7f144912d49de3fc497c1ec2e8e0b7f714
The window manager now keeps track of the overscan of
each display, with an API to set it. The overscan impacts
how it positions windows in the display. There is a new set
of APIs for windows to say they would like to go into the
overscan region. There is a call into the window manager to
set the overscan region for a display, and it now has a
concept of display settings that it stores presistently.
Also added a new "wm" command, moving the window manager
specific commands from the "am" command to there and adding
a new now to set the overscan region.
Change-Id: Id2c8092db64fd0a982274fedac7658d82f30f9ff
If starting window is added to arrays like mViews in
WindowManagerImpl.java, but not accepted by WindowManagerService,
we leak starting windows. To avoid leaking, remove the view
from WindowManager.
Change-Id: I4d98b883e9dfaf5e71bdece385643ba1b59b2633
