WindowMagnificationGestureHandler has higher priority to address
motion events. When the user put two fingers down on the screen,
magnification gesture detector will intercept all motion events.
It ends up the user couldn't perform any multi-finger gestures.
To fix it, we make magnification gesture detection more accurate:
1. swiping gesture sucesses only with one finger.
2. Regarding two-finger gesture, only swipe or stay on the screen
over a duration will be recognized.
Bug: 163016948
Test: manually test: enable Talback and perform 3-finger swipe gesture
atest com.android.server.accessibility.magnification
Change-Id: I310cf6e3fb2cb2b5b6fbc6a0ba9f0aa1d219b4df
This change fixes the issue where AccessibilityService was not able to
dispatch a gesture if a device doesn't have a touchscreen hardware
feature, resulting the behavior gap between CTS and framework.
With this CL, AccessibilityService can dispatch a gesture if the device
declares touchscreen or faketouch hardware features.
Bug: 177021722
Test: AccessibilityManagerServiceTest AccessibilityServiceConnectionTest
Test: CtsAccessibilityServiceTestCases on crosshatch and kindred
Change-Id: I8a1e4884d1283705d409ed38e35047ec2dcd89f0
Since WindowContext won't add WindowToken from the client side,
addWindowTokenWithOption is no more needed. Also remove the logic
to invoke removeWindowToken from the client side.
Bug: 159767464
Bug: 153369119
Test: atest WindowManagerServiceTests WindowManagerPermissionTests
Change-Id: Ib0c948dca223cf8d056865ce3a0d4adaef07d247
Cnfig flag, config_magnification_area, determines if the device
supports magnification area or not.
If OEM doesn't support magnification area, we should adjust the
magnification capability setting and window magnification prompt
setting.
Bug: 177371954
Test: atest SettingsBackupTest
Change-Id: I67947285eb6a73b8e0e21d1db866c426a0ea49d7
(cherry picked from commit f9d7150a5c)
Merged-In: I67947285eb6a73b8e0e21d1db866c426a0ea49d7
* changes:
Notifies updating magnification switch visibility when the magnification shortcut is triggered
Notifies showing magnification switch when the touch interaction starts or ends
Not need to show magnification switch UI when magnification scale is changed
When an A11y service is enabled, it would be added into the list
of the crashed services after doing force close. Then users can't
enable this service until users disable this service again based
on our crashed mechanism now.
The A11y service would be removed from the list of enabled
services after doing force close. We need to remove this service
from the list of the crashed service at the same time to make sure
users can enable this service next time immediately.
Bug: 174616279
Test: a11y CTS & unit tests
Test: manual testing by the steps in the bug
Change-Id: Ie09a11dd2eb2ed7237b580e69c46751ef404b96a
Since in reality only one service at a time (and maybe ever) will care
about these focus data, letting services change these parameters and
leaving it alone even that service is disable.
Bug: 175732114
Test: a11y CTS & unit tests
Change-Id: Ic1f9d29c35ebccbabb6b35b9f113920b992af0df
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interupt an API call, but we can stop in between API calls.
On the service side, we have to seprate the prefetch callbacks from the
find callback. And we have to make it asynchrnous. It does dispatch into
the main thread, so the AccessibilityCache can remain single threaded.
When the calls are interupted on the application side, returnPendingFindAccessibilityNodeInfosInPrefetch checks the find requests that are waiting in the queue, to see if they can be addressed by the prefetch results. If they can be, we don't have to call into potentially imperformance application code.
Bug:30969887
Test: Performance measurements, tried it out by hand to see if their are any bugs. CTSAccessibility*
Change-Id: Ia8f1152afa3987f262f37ed4583775acdd32db43
When the magnification is off then a user toggles on magnification by the
magnification shortcut (a11y button or triple-tap gesture),
the switch button should be shown immediately.
When the magnification is on then a user toggles off magnification by the
magnification shortcut, the switch button should be removed immediately.
Bug: 170976389
Test: atest FullScreenMagnificationGestureHandlerTest WindowMagnificationGestureHandlerTest MagnificationControllerTest
Change-Id: I28869f0954d0befd5c675e5f22c303d128e8d8d3
In the previous design, we notify syetem UI that magnification scale
is changed and it is time to show the magnification switch button.
While the new UX behavior is changed now, we want system UI get
the notification whenever a user touch interaction on the screen starts,
ends or cancels when the magnification is activated.
Doc: go/window-magnify-ux ,page3
Bug: 172631612
Test: atest AccessibilityManagerServiceTest FullScreenMagnificationGestureHandlerTest
MagnificationControllerTest WindowMagnificationGestureHandlerTest
Change-Id: Id3243702e8edea98da5c1230fd8d74973f002377
It doesn't seem like this would add a performance bump, but it does make
code quite ab it more complex (especially the prefetching CL).
Let's remove it to avoid bugs.
Test: CTSAccessibility* Tried it by hand.
Bug: 30969887
Change-Id: Ibc2fb856dbb1a0f7786882d4b89d71bbcb7e5af2
In the new design, we show the magnification switch UI when the touch
interaction starts, ends or cancels.
We don't need to notify showing the switch UI when the scale is changed
because the new design includes the case for scale changes.
So we can remove the implementation of onMagnificationScaleChanged.
Bug: 172631612
Test: atest FullScreenMagnificationGestureHandlerTest MagnificationControllerTest
Change-Id: I245b611d8a6a50aeff008257cbb87dfed8fd8962
1. Define and implement new APIs to set and get the stroke width
and color of the A11y focus rectangle.
2. New an AccessibilityFocusApperanceData variable with the default
value in the A11yUserState class, and it would be used in the A11y
framework.
3. When A11y services sets the stroke width and color of the focus
rectangle, A11yUserState will apply the same value through
A11yServiceConnection and notify this change to A11yManager.
4. When A11y services customized the data is disabled, reseting the
data in the A11yUserState and notifying this change to A11yManager.
5. When the ViewRootImpl gets the A11yFocusDrawable, it changes the
strokewidth and the color of this drawable based on the value from
A11yManager.
Bug: 141144573
Test: a11y CTS & unit tests
Change-Id: I1493f17f7cc25744e1435c9070218c6f7efa8bcf
This change doesn't change any user behavior.
It's refactoring that reduce the common code and logic.
1. Moves the common logic of onMotionEvent to the parent
class, MagnificationGestureHandler.
2. Moves some of the debug flags to the parent class.
Bug: 174291719
Test: atest com.android.server.accessibility.magnification
Change-Id: If0a4a5e934a650b40e064dc3a0b72ce68780409b
This change doesn't change any user behavior.
It's refactoring that reduce the common code and logic.
1. Adds the common varibles to the parent class, MagnificationGestureHandler
for fullscreen and window MagnificationGestureHandler.
2. Moves the implementation of onMagnificationScaleChanged() from
AccessibilityManagerService to MagnificationController.
Bug: 174291719
Test: atest AccessibilityManagerServiceTest FullScreenMagnificationGestureHandlerTest
MagnificationControllerTest WindowMagnificationGestureHandlerTest
Change-Id: Ic4d6c966600a113fd06e7165353e014aca3189bf
To ensure the user could see whole content, we apply big text style
Bug: 174131708
Test: adb shell settings put secure accessibility_show_window_magnification_prompt 1
Change-Id: I2ccec4e2e0167c1d0b2b7d81bafa8c38497388dc
Moving this class out of android.os will reportedly
greatly reduce ART overhead.
Test: compiles
Test: atest FrameworksServicesTests FrameworksCoreTests
Bug: 165817914
Exempt-From-Owner-Approval: no-op refactoring
Change-Id: I1f3e77120979e2f336e5f42e4ec6e459d6492083
Once one of the fingers has moved more than (fingerCount * touchSlop), gesture detection will start and will not cancel no matter how slow the user moves. The reasoning behind speed requirements in one-finger swipes is to distinguish between touch exploration and gesture detection. There is no such problem here.
Bug: 172670126
Bug: 170902208
Bug:162521649
Test: atest GestureManifoldTest TouchExplorerTest AccessibilityGestureDetectorTest FrameworksServicesTests:TouchExplorerTest
Change-Id: I760036415192cd1368a06b04355b775299c29d16
Change-Id: I796d6e5476cb5dc60aa85ba33c04ad62dce88eba
The agreed-upon behavior has always been that after gesture cancelation, touch explorer would exist in essentially a dead state.
It should not be possible to execute a two-finger passthrough gesture for example after doing an invalid gesture.
This is likely why we see GESTURE_PASSTHROUGH in cases where we expect GESTURE_UNKNOWN.
Fix: 171421786
Bug: 162521649
Test: manual
Change-Id: Idce921c5278dea174ec5dad5cecf046f12ab113d
Change-Id: Ic71246adc613ea60d3f25974e4085814c4b3211d
The magnification mode is full-screen when the migrating deivce turns on
magnification settings.
We show a notification prompt the user that new window magnifier to
guide the user to take a look.
Bug: 168635084
Test: 1. adb shell settings put secure \
accessibility_show_window_magnification_prompt 1
2. use full-screen magnification to see if it works well.
atest WindowMagnificationPromptControllerTest
atest FullScreenMagnificationGestureHandlerTest
Change-Id: I40dfc49307d2dad380f1e662960d35f5cc5e7524
Under some circumstances, remaining in gesture detecting state after gesture cancelation can render TouchExplorer unresponsive to touch input. The clear state is unresponsive to everything but ACTION_DOWN.
Bug: 171421786
Test: atest GestureManifoldTest TouchExplorerTest AccessibilityGestureDetectorTest FrameworksServicesTests:TouchExplorerTest
Change-Id: I9516d3613e92baf16186c24a269866a4143cafc3
Change-Id: I42780f5c733f20b99cb95952d9035109e57750cd
User does the triple tap operation, but the gesture detection
becomes to doubleTapAndHold because the timing of the motion
event. Then the long pressing data is created but not be cleared
when the state returns to STATE_CLEAR.
Adding the long pressing data reset to fix this issue.
Bug: 162521649 and 163298552
Test: a11y CTS & unit tests
Change-Id: I40d89ea958bee619c64799de591be96bf92efbfc
Merged-In: I5fc23a14b0a4ae3c7c012cb4ed8dc924c00e7fe9
The agreed-upon behavior has always been that after gesture cancelation, touch explorer would exist in essentially a dead state.
It should not be possible to execute a two-finger passthrough gesture for example after doing an invalid gesture.
This is likely why we see GESTURE_PASSTHROUGH in cases where we expect GESTURE_UNKNOWN.
Fix: 171421786
Test: manual
Change-Id: Idce921c5278dea174ec5dad5cecf046f12ab113d
Change-Id: If9aeb611417bba08edd9f5a11f3d107c0b477bb8
User does the triple tap operation, but the gesture detection
becomes to doubleTapAndHold because the timing of the motion
event. Then the long pressing data is created but not be cleared
when the state returns to STATE_CLEAR.
Adding the long pressing data reset to fix this issue.
Bug: 163298552
Test: a11y CTS & unit tests
Change-Id: I5fc23a14b0a4ae3c7c012cb4ed8dc924c00e7fe9
