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)
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
Add API for handling nested pre-processing of accessibility events
similar to nested pre-scroll or pre-fling. This allows custom views to
delegate a nested scroll to a parent via the accessibility system.
Use this functionality to allow opening the ResolverDrawerLayout via
accessibility commands.
Bug 18827274
Change-Id: Icd5a502605b78a861bb03e7b11923841a72eb9ab
Reverse-translate the canvas before passing to Drawable.draw() so that
we don't double-apply the drawable's translation.
BUG: 18904688
Change-Id: I8450de9b240ddeae887b4e1003c0608da814a001
The accessibility manager has APIs for clients to observe changes
in accessibility, touch exploration, and high contrast states. The
notification of the listeners has to be done with no lock held but
in an attempt to do that the code was incorrectly iterating over
the copy on write collection.
bug:18840784
Change-Id: I6803ff1657fbf6b0cc7936671d5bbdebb5cbf6bb
As a bride-gap solution to click on partially covered views in accessibility
mode we compute a point on the screen where to send a down/up event pair.
A heuristic we used was that if the action target is covered by a view that
that has a touch listener we consider the target obscured by the one with
the listener. However, this generates false positives, for example the target
is covered by a view that observers touches for scrolling but not clicking.
bug:18782023
Change-Id: I31ff34011d45667f1eddda47373ec00e4a23dbf6
Delegation is broken for widgets, but this fixes the most egregious issue
where TextViews that are top-level list items weren't handling CLICK
actions correctly. This will still need work, since now the focus action
won't run, but it's an improvement.
BUG: 18736135
Change-Id: I808ef628198946cc87f13c53d6245cd162a1e517
In accessibility mode to click a view we computed a point where to send
down and up touch events. The logic that computes where to send the
events was not clipping the bounds of the child to these of the parent.
As a result we wrongly computed we can send the events in a location
of the child that is outside of its parent, thus the click having no
effect or clicking the wrong thing.
bug:18672945
Change-Id: If9c452e7e5b196f699db33d37dbc6775d5d1622a
getChildVisibleRect was enhanced to obey the official contracts for
clipping children and clip to padding. Unfortunately this meant that
ViewGroups with no parent have no way of checking if they will be
clipped to their own bounds and therefore should clip a child rect.
Treat orphaned view subtrees as entities that clip to the root view
bounds to preserve prior CTS guarantees.
Bug 18642973
Change-Id: I9fcbeb0e92cd6715cd9184183d36889614ed0bed
Bug: 18521508
Fix an issue where an RNA's native object was destroyed
before the java-side object was started
Change-Id: I487fb476e0ecdf7000515f4f7320e8cfbc50a52b
There was a weird disconnect between setPressed() and hotspot propagation
behavior. This makes hotspot propagation work like setPressed(). Also
fixes ripple animation during drag-to-open.
BUG: 18631557
BUG: 18593243
Change-Id: Id4adf5d815e4d426b4182aac4d0c780f04472ae4
Nodes that are clicked can change state as a result of a click,
e.g. a check box. The accessibility service may decide to get the
source node from the click event to probe its state and get a
cached state since the window content changed event is after the
click one. Therefore, we have to clear the state of the click
event's source from the cache to ensure the client can query the
latest state of that source.
bug:18625975
Change-Id: I9e339c2fdcf74f260bb8ad86b9b873f7ddd75f19
In accessibility mode we send down and up events activate a view. We will later
switch to accessibility actions but for now as a bridge-gap we compute a point on
the screen where to click for activating the view. The heuristic we use has edge
cases such as a view that handles all touch events but does not have any listeners.
In this case we do not ignore the target view's area covered by a view that handles
all touch events. As a result we click on the wrong target. While we cannot solve
this generically, in the case of standard components such as HorizontalScrollView
we can.
bug:18612258
Change-Id: If8482aac0d0ea53c5c90367d099d1b8d3a4559ed
Accessibility services may opt-in to introspect the interactive
windows on the screen. If window introspection is enabled there
is a case where some events from a showing window are received
before the updated window state from the window manager. Now the
window manager sends over the windows before notifying the app
for the focus change.
bug:18625996
Change-Id: Ic481e01efbe12dc92f090f799feeb236672fc7b3
Bug: 18203577
The issue occurs as a result of performTraversals() both doing
a window relayout call *and* early-returning because it's not dirty.
To fix this pauseSurface() returns whether or not the RT-side is
"dirty" to force ViewRootImpl to do a draw even if mDirty is
otherwise empty.
Change-Id: I534f367e75d18d273ebf14df3927f5c464ef6bef
