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
This reverts commit fad9555217.
Because it just didn't work. (The views kept aggressively
re-applying their preferred flags every time view attributes
were aggregated.)
We'll pursue the original strategy, like lights out mode in
HC: if you want to tickle this mode, un-set and re-set the
flags (preferably synchronized with the global SystemUI
visibility state as reported by onSystemUiVisibilityChanged
callbacks).
Bug: 5052456
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
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
calls.
If a View is added to a ViewGroup during the ViewGroup's
onAttachedToWindow method, the child can receive two calls to
onAttachedToWindow. Guard against this.
Change-Id: I845d0cb2c9172071eee1eadc6bc2dd282ee0ef43
1. Added flags to the search method to specify whether to match text or
content description or both.
2. Added test case for the seach by content description.
3. Updated the code in AccessibilityManager service to reflect the latest
changes there so test automation service works - this is the fake
service used for UI automation.
Change-Id: I14a6779a920ff0430e78947ea5aaf876c2e66076
...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
Bug: 5265529
Rewrote the velocity tracker to fit a polynomial curve
to pointer movements using least squares linear regression.
The velocity is simply the first derivative of this polynomial.
Clients can also obtain an Estimator that describes the
complete terms of the estimating polynomial including
the coefficient of determination which provides a measure
of the quality of the fit (confidence).
Enhanced PointerLocation to display the movement curve predicted
by the estimator in addition to the velocity vector.
By default, the algorithm computes a 2nd degree (quadratic)
polynomial based on a 100ms recent history horizon.
Change-Id: Id377bef44117fce68fee2c41f90134ce3224d3a1
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
Forgetting to release it was "safe" in that GC would eventually
tidy it up anyway, but in the meantime it was possible for a user to
do lots of drag operations, racing ahead of the progress of the garbage
collector, and wind up with drags failing because we'd run out of
surface slots due to all the piled up stale drag shadows.
Change-Id: I7ac93b13cc9996dda04a404571fbc44cb4314694
Fixes up some recycling of TypedArray objects to reduce the
number we need to allocate during inflation etc.
Change-Id: I948dccc052997779001eaa99db2a710b04be01ae
1. Added an AccessibilityDelegate class in View which can be set by
a client that wants to cutomize accessibility behavior via
composition as opposed to inheritance. Insead overriding a new method in
View thus being bound to the API version that introduced this
method a developer can conditionally inject the accessibility
customization if the platform API version is heigh enough. The
developer will have to override the method of interest of the
delegate. The default implementation of the delegate methods is
the same as that of View in the case that there is no delegate
set. If a delegate is set calling an accessibility related method
on View will be handed off to the corresponsing method of the
delegate.
bug:5259555
Change-Id: I00e750e22e5e7164a1b571cb3d12ecaf4ab93db4
The DIRTY flag is used to track which elements of the view hierarchy need
to be redrawn on the next drawing operation. This flag is set on the parent
hierarchy of a view when that view is invalidated. There is an optimization for
opaque views that tells the parent that it is dirty, but that it need not
redraw its own content because the view will cover it (since it is opaque).
This dirty-opaque logic breaks down in the current code because we only set
these dirty flags on the parent hierarchy, not on the view itself. In the situation
raised by this bug, we would invalidate the parent container directly (which does
not case the dirty flag to be set), then we would invalidate a child of that view.
Because the child is opaque, the DIRTY_OPAQUE flag would be set on the parent
container. This would cause us, in the later rendering process, to skip the
drawing on that parent container, assuming that it was only asked to be redrawn
because of its opaque child's invalidation.
The fix is to now set the DIRTY flag on an invalidated view, not just on its parent
hierarchy. The DIRTY_OPAQUE logic will avoid setting the opaque flag on views/parents
that are already marked DIRTY, thus an invalidated parent will be correctly drawn
during the drawing process.
Change-Id: Ib5e014a125a4f5168f6a5a3166e941474659aca5
1. There was a bug that was not handling correctly the
case for which the interrogator requests an accessibility
node info and the message describing how to fetch the
latter for the same process case was delivered after the
code that checks whether the message is there in order to
dispatch it is executed. Now the message handling is done
correctly - the caller checks if the message is present and
if so processes it, otherwise the caller sleeps and is
interrupted if such a message arrives.
bug:5138933
Change-Id: I4c2940b46c9a52a51c5ee48b83ca6811489765d6
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
1. Some invisible views' text was reported by accessibility events.
2. Accessibility actions could have been perfromed on invisible views.
bug:5264355
Change-Id: I68184fb436a3e10e947ec6f1eae02aa3d0d1cb7f
This new hidden API is called by ViewRootImpl when there is a pending
transition but the parent window is not visible.
Change-Id: Idd6a0959b391fae542e675e8740b6a16f8963678
There's a problem with how LayoutTransition cleans up after itself
when the target view is in a Window that is not on the screen.
The quick fix is to always start (and therefore properly end and clear)
transitions, regardless of whether the window is in the tree.
Change-Id: I23f4f4f04176f3943e5c6e1d78acba0190a96930
