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
automerge: 6e9f276
* commit '6e9f276ff1554b59692a1820f60217307460308b':
Accessibilty: Cannot click on views in a scrollable container covered by the toolbar.
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
