| a0260a17093d3f65871564505c508d9fcd190d67 |
|
17-May-2017 |
Phil Weaver <pweaver@google.com> |
Stop system process crash in TouchExplorer
We need to straighten out this state machine so we can
fix bugs in it without a high risk of creating others
(b/38246304). In the meantime, catching this exception at
least allows the device to keep operating.
Bug: 37338581
Test: Reproduced the conditions of the crash. Verified that
we now print the log message.
Change-Id: I1f4f84b5529b2bf638e225d474808e3d42484e78
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 0adfbd33c884ce80ebe161428d7a8ae9e6aced03 |
|
17-Feb-2017 |
Phil Weaver <pweaver@google.com> |
Use accessibility action for touch exploration
Explore-By-Touch has been dispatching touch events to the screen
rather than using the accessibility API. This was intended as a
workaround for apps that did not properly handle accessibility,
but the workaround itself has been causing bugs in corner cases
where properly accessible Views are partially covered by windows.
This CL first tries to dispatch a click action, and falls back on
the touch dispatch only if the click action fails.
Bug: 35200501
Bug: 26216304
Bug: 20665958
Bug: 34949365
Bug: 34844480
Bug: 29535082
Test: Poking around with first party apps and TalkBack works fine.
This behavior isn't covered by automated testing.
Change-Id: I9cc18399d8f40f7381dfcbef91b5991b711bb7f1
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| ec1783828e541f22e93e67ec80511b9187bc93be |
|
13-May-2016 |
Zachary Kuznia <zork@google.com> |
Ensure MotionEvent.split() won't be given an invalid value.
b/27496784
Change-Id: I28bb4ac5bb8a705e7af9b22b2b56cd4061aa06a0
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| fd6aa8a1fa6345030c382d7f2d9eac456b425f55 |
|
12-Mar-2016 |
Zachary Kuznia <zork@google.com> |
Fix double tap issue in TouchExplorer
In certain conditions, the first tap in a double tap could be detected
as Touch Exploration. This ensures that cannot occur.
Change-Id: I20941be54413534d9dc74e5a3152c27dd0c998fe
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| bf1cf52663414eec1d80d23edc029bf6223adb3b |
|
24-Feb-2016 |
Zachary Kuznia <zork@google.com> |
Ensure AccessibilityGestureDetector only returns true when a
callback returned true.
b/26987664
Change-Id: I52687120f784ec958802a9c93b767c2b8f6a7e38
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 0bc3cc9c2fdc18eb305088adb9be72953df14473 |
|
18-Feb-2016 |
Zachary Kuznia <zork@google.com> |
Fix crash when cancelling an accessibility gesture with ACTION_UP.
b/27090049
Change-Id: I7a5b65c4e96513539d820c9a2bef99272fb24680
(cherry picked from commit 3951e3547f2ebb5ec228b8776855e9f244b1e9e9)
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 9254b3e336a01ff79742882bd98860b48ebae379 |
|
21-Jan-2016 |
Zachary Kuznia <zork@google.com> |
Make AccessibilityGestureDetector handle gesture detection start and end.
Change-Id: I2c1861d5d6c5c0dc921e62f03ee6283f1f7a62b6
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 407df712e2a381e0227eb780786128a50bfcf5f5 |
|
16-Oct-2015 |
Zachary Kuznia <zork@google.com> |
Move stroke buffer and gesture recognition out of TouchExplorer.
This also adds a return value to the callbacks on
AccessibilityGestureDetector.Listener, so that the listener can indicate if the
event has been consumed, and processing should be halted.
b/25021896
Change-Id: If4d366ff207c1cebd0e3f7dab5f27a2037ddb510
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| c18f2fdfcf8ec7a8534c032c4102739edb7f1c5e |
|
29-Sep-2015 |
Zachary Kuznia <zork@google.com> |
Encapsulate a11y gesture detection in an external class.
Change-Id: I59e0c25c06ba296822c7afb9f8623989986fde96
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| c78d64132228f1771f4df690e9c8b4e47e0d3eca |
|
25-Sep-2015 |
Zachary Kuznia <zork@google.com> |
Use the standard GestureDetector to handle double tap and hold in TouchExplorer.
b/24407329
Change-Id: I1cbd1a232bd642eb9bf87548b1a3d1afe48a9bed
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| c052c635eebaccebc099bb107ad7846df54ab2ad |
|
24-Sep-2015 |
Zachary Kuznia <zork@google.com> |
Use the standard GestureDetector for Double Taps in TouchExplorer
b/24339804
Change-Id: I96fa1287fa941178fb9970ceb34d95a3604e6815
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 976724e81bca33dc48347f88633a37a195b9e4ea |
|
01-Sep-2015 |
Toni Barzic <tbarzic@google.com> |
Feed mouse and keyboard events to EventStreamTransformation
Updates AccessibilityInputFilter to pass keyboard and mouse events
through enabed EventStreamTransformations.
This is done in preparation for implementing Autoclick on mouse stop
feature, which depends on those events.
Existing EventStreamTransformation implementstions are modified to
non touchscreen motion events and key board events.
Adds stub EventStreamTransformation (AutoclickController) that will
be used to implement autoclick feature.
Implements key event filtering as a separate EventStreamTransformation
(instead of doing it directly in AccessibilityInputFilter).
Introduces private EventStreamState classes to AccessibilityInputFilter,
which keep track of whether event sequences for different input sources
have started, and help reduce code duplication when determining whether
an event should be fed to registered EventStreamTransformers.
BUG=23113412
Change-Id: If115799bbe4debce48689370ff5ea9fa6dab9639
/frameworks/base/services/accessibility/java/com/android/server/accessibility/TouchExplorer.java
|
| 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
|