Information about the chin is now part of the config.xml instead of the
theme. It is retrieved by WindowManagerService and passed to the clients
as insets. Clients can adjust their behavior in a way that makes it
invisible to the user, that part of the surface doesn't actually exist.
Bug: 19908853
Change-Id: Iedf57bf3c848201b854f91ffeb3b59187d375c1f
AccessibilityNodeInfo refresh was getting the latest cached
state but this is not good enough as an accessibility service
can execute an action on the node and then refresh it to get
the new state.
bug:16954787
Change-Id: I004b4987b8dc423a2ab7031a4fbfe64365ddd7fe
(cherry picked from commit 5738fec00d)
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
The special logic for clicking on views in accessibility mode should not
prevent event interception and if a view interceptes the gesture we must
clear the special flag and do normal event dispatch. Also once we have a
view handling the touch gesture we do not need the special flag as we
know what will handle the event. This tightly follows standard event
dispatching.
bug:19252492
Change-Id: I0c9764c5050ec73f5f7980f3f0340dd9509a725a
A view that has an accessibility node provider should not have real children
since the provider is responsible to generate the node infos for the subtree
rooted at its hosting view. This is how the APIs are designed to work. However,
it is a common mistake and if this occurs the accessibility services
introspecting the screen get into an infinite loop.
The framework now does not add the real children of a view with a node provider
to the list of accessibility children. If the developer wants them exposed they
have to do that via the provider APIs as per contract.
bug:19297093
Change-Id: I1b01b1e4a85e1c397886fcd2506b434beb063687
The clicking logic was missing the case where a child of the accessibility
focused view reacts to the injected down up events for clicking. This
results of a whole class of views being non-interactive. Now if an event
is targeting accessibility focus and the dispatching view group has this
focus, we clear the flag before dispatching to children, so they can
handle the event rather ignoring it becuase they are not accessibility
focused.
bug:19252492
Change-Id: I6ac25bb7a50b35bb638ca4bfb9fc4198d08c2d4d
We were using an approximation to determine where to send a pair of down
and up events to click on the view that has accessibility focus. We were
doing reverse computation to figuring out which portion of the view is
not covered by interactive views and get a point in this region. However,
determining whether a view is interactive is not feasible in general since
for example may override onTouchEvent. This results in views not being
activated or which is worse wrong views being activated.
This change swithes to a new approach to activate views in accessibility
mode which is guaranteed to always work except the very rare case of a
view that overrides dispatchTouchEvent (which developers shouldn't be
doing). The new approach is to flag the down and up events pair sent
by the touch explorer as targeting the accessibility focused view. Such
events are dispatched such that views predecessors of the accessibility
focus do not handle them guaranteeing that these events reach the accessibiliy
focused view. Once the accessibiliy focused view gets such an event it clears
the flag and the event is dispatched following the normal event dispatch
semantics.
The new approach is semantically equivalent to requesting the view to perform
a click accessiblitiy action but is more generic as it is not affected by
views not implementing click action support correctly.
bug:18986806
bug:18889611
Change-Id: Id4b7b886c9fd34f7eb11e606636d8e3bab122869
bug:19113359
Ensures that ViewOutlineProvider#PADDED_BOUNDS is always kept up to
date with the view's padding.
Change-Id: I5e090bd8272e89d6b8b9055dbe95ef3d45333fcb
To click a view we were computing a click location by ignoring overlapping
views that are actionable. However, detection whether a view is actionable
is not always possible as the view may handle touch events directly. This
leads to unhandled edge cases. We are taking a conservative approach and
ignore all overlapping siblings regardless if clickable. This is also has
limitations but hopefully less frequent edge cases.
bug:18889611
Change-Id: Icea0b7b3e2d4ed53e50e01cb6a99b880be560b14
In accessibility mode we calculate a point where to click in the accessibility
focused view as a bridge-gap solution before switching to accessibility click
actions. We cannot detect whether a view is covered by another one that consumes
all touch events, and therefore we may click on the wrong target. This was the
case with the toolbar. As a result a partially scrolled view in a scrollable
container covered by a toolbar cannot be activated and this is not an edge case.
bug:18986806
Change-Id: Ib41470c39806cec13e9b00b319879cd7f3412ab5
