| ded133c446fa9d0d23e6bde19a66fb2ce3980491 |
|
31-Jan-2015 |
Svetoslav <svetoslavganov@google.com> |
Fix broken activation of the selected view in accessibility mode.
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
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 47b9c1524fe20b9ae2b210acdcad64f764df68e0 |
|
04-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
TouchExploer computes incorrectly the click location.
If there is accessibilty focus and the user touch explores
location that does not change accessibility focus that is
not in the app window, e.g. system bar, double tap does not
click on the system UI affordance.
bug:17588024
Change-Id: I6c8c0f65b208ae1d3f31d7f06b0721dc223ec19f
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 76716c5a180aa471c6973ca7aa03c7f2da677823 |
|
03-Oct-2014 |
Svetoslav Ganov <svetoslavganov@google.com> |
Revert "TouchExplorer computes incorrectly the click location."
This reverts commit 851a5059a47cbf76e530c9d050a677cb6e3f8657 as
it creates a regression. Let us revert this and correctly fix the
issue the original change was trying to address.
bug:17789608
Change-Id: I8abb1a61d5310430e839e4ef60e7ca5cc0cbdd80
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 8d412fe18b9ce8cf71ce57c380e7f312e4667667 |
|
20-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
TouchExploer computes incorectly the click location.
If there is accessibilty focus and the user touch explores
location that does not change accessibility focus that is
not in the app window, e.g. system bar, double tap does not
click on the system UI affordance. This is due to obsolete
logic from the time where accessibility focus was only in
the active window at the time of double clicking.
bug:17588024
Change-Id: Ib780103e873d8a2afd3b35de3227d54116f1a1b0
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 7498efdc5e163d6b4a11db941c7d13c169d37284 |
|
04-Sep-2014 |
Svet Ganov <svetoslavganov@google.com> |
Clicking on partially coverd views by other views or windows.
In touch exploration mode an accessibility service can move
accessibility focus in response to user gestures. In this case
when the user double-taps the system is sending down and up
events at the center of the acessibility focused view. This
works fine until the clicked view's center is covered by another
clickable view. In such a scenario the user thinks he is clicking
on one view but the click is handled by another. Terrible.
This change solves the problem of clicking on the wrong view
and also solves the problem of clicking on the wrong window.
The key idea is that when the system detects a double tap or
a double tap and hold it asks the accessibility focused node
(if such) to compute a point at which a click can be performed.
In respinse to that the node is asking the source view to
compute this.
If a view is partially covered by siblings or siblings of
predecessors that are clickable, the click point will be
properly computed to ensure the click occurs on the desired
view. The click point is also bounded in the interactive
part of the host window.
The current approach has rare edge cases that may produce false
positives or false negatives. For example, a portion of the
view may be covered by an interactive descendant of a
predecessor, which we do not compute (we check only siblings of
predecessors). Also a view may be handling raw touch events
instead of registering click listeners, which we cannot compute.
Despite these limitations this approach will work most of the
time and it is a huge improvement over just blindly sending
the down and up events in the center of the view.
Note that the additional computational complexity is incurred
only when the user wants to click on the accessibility focused
view which is very a rare event and this is a good tradeoff.
bug:15696993
Change-Id: I85927a77d6c24f7550b0d5f9f762722a8230830f
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| d2b3e034d157104a0fe4542193a7694f9034efce |
|
04-Sep-2014 |
Alan Viverette <alanv@google.com> |
Don't switch to touch exploring state on pointer up
BUG: 17388688
Change-Id: I146aa2290acf0a587eaccafa5a208ee1cbd84aa5
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| dc6d1a9cc3a23c26c786a732e729fdd418b57d29 |
|
29-Aug-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix the global gesture to enable accessibility.
1. There was a bug in the touch explorer which was crashing almost
every time after accessibility was enabled via the gesture. The
problem was that in dragging state when a finger goes up we were
not transitioning to touch exploring state.
2. The global actions dialog was not going away after enabling
accessibility while it should as the user brought it up to
turn accessibility on rather to interact with global actions.
bug:15254250
Change-Id: Iaa45f758e09566822775b53e87d2980138e85ef9
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 1e0d4af9986c8c2a658769a63bf8b385d25e0435 |
|
11-Apr-2014 |
Svetoslav <svetoslavganov@google.com> |
Adding system support for a single accessibility focus.
Now that we have APIs to query all interactive windows and allow
an accessibility service to put accessibility focus in each of
them we have to guarantee that there is a single accessibility
focus. This is required for correct operation of the touch
explorer as on double tap in clicks in the center of the focused
area, hence having more that one focus is an issue. Also the
system is maintaining a single input focus so now accessibility
focus behaves consistently with that.
bug:13965563
Change-Id: I0b5c26dadfabbf80dbed8dc4602073aa575ac179
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|