ded133c446
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