Accessibility services crash when changing users for several
reasons. we were looking up permissions for the current
user, which wasn't the user who created the service. We also
end up resetting the accessibility state, which reads user-
specific settings and thus must be done with the calling
identity cleared.
Bug: 27594523
Change-Id: I2b910d77704a6054b3a591c38f54d3ed3a2dc427
We were checking if a coordinate was inside its window before
compensating for magnification.
Bug: 31054088
Change-Id: I4993d84e877fcf3d01382b3cf1c10e2fab58dbba
This reverts commit c34649411d053185b3572c4cd924e6f14295d8cd.
Dispatching accessibility events in their own thread is causing Chrome and gmail to crash. We've identified two issues: Chrome is allocating strings natively using references that aren't valid outside of their thread, and the text is being set to values that are changed in the UI thread.
I'm going to resolve these issues on master by making deep copies of the strings, but that change will have its own performance implications.
Since we were bit almost immediately by an unexpected result of this change, and I need to erode its benefit by making deep copies, I think it's a bad bet to push it into MR1.
Bug: 31042124
Change-Id: I6f5c225a9197036db43fd0ac6008447b22617525
We were failing to create a death link for the service that
replaces the crashed a11y service. Adding an invariant that
mService is always linked to death if it is non-null.
Bug: 31044551
Change-Id: I98b6a3969cfacb0309e19938899a51c809249d6b
Original commit:
Dispatch a11y events in separate thread.
Moves the IPCs into a separate thread, where they should affect
jank a lot less.
Bug: 30183085
Change-Id: I7bc8a777fe76dd76f661cc3e3e1d45a2a28df0d2
In ag/1273924, we stopped restarting services that were
still bound. When the package changes, however, the system
unbinds from a service and has no way to tell us that it is
not going to restart it (as it would if the service
crashed.)
Now we listen for package updates and unbind affected
services. The services will then be restarted as there will
be enabled services that are no longer bound.
Bug: 30866905
Change-Id: I375edfd6a37ed25f959ec354930cec8f288deb6b
Make sure we don't try to dispatch key events to services
that have died. Doing so crashes the device.
Bug: 30866905
Change-Id: I1cc0515cca8924b0c2744de98ac75a901b94246d
This type behaves like a normal TYPE_APPLICATION, except that WM
will always wait for it to be drawn before starting a transition.
WM always waits for TYPE_BASE_APPLICATION (main window), but for
TYPE_APPLICATION, it only waits if the window relayouts to visible
and gets a surface before the main window is drawn. If main window
itself is ready very fast, transition could start without the other
window.
bug: 30830849
Change-Id: Ife71a9812db7c8eba6ee4ead10ce4f31d9e93b40
Changing the service side to accept descriptions of
motion events, not motion events themselves, so we can
control their creation.
Bug: 30647115
Change-Id: Ia6772a1fc05df91818e3f88959d1e2b4a35fe0cc
We've seen some jitter in motion events with accessibility
enabled. We can eliminate it by not passing motion events
through the filter if we know they won't be affected.
Bug: 30183085
Change-Id: I0ecc8d5a39c8e370fc3a8ab85c6357251a31f8ad
We were confusing handling of services that were unbound with
those that had crashed. We would lose track of services that
has crashed, start new ones, and then when the system restarted
a killed services we would have multiple instances running. It
was possible for this to get very out of hand.
Bug: 30306689
Change-Id: I4e63d25b6d2fec3ec68f450a4602898c43a2b2ad
- Removed Secure.ACCESSIBILITY_DISPLAY_COLOR_MATRIX, it's not desirable
to persist the actual color transformation matrix.
- Refactored all SurfaceFlinger transforms to DisplayTransformManager,
which allows color transforms to be set independently from the a11y
manager service.
Bug: 30042357
Change-Id: Iefa477dedb66aac90e1218e327802a3fab6899ed
Some minor but needed changes to the class under test to
gain visibility for tests to do things like make events
on Handlers happen on demand to verify various event ordering.
Change-Id: I5096de697906f8d28b47f47dc2be2f8199ee4e19
Changes were discarded if they arrived too quickly in
A11yManagerService. Excuse content change events from
throttling at this level.
Bug: 29355115
Change-Id: Ifd9da07315ce0c18f59c1dad6a621110ad48343b
AccessibilityManagerService#unlockUser was assuming that we should
switch to the unlocked user's state. If that user is a new work
profile, this transition disables all accessibility features.
Bug: 28726050
Change-Id: I3797d34b580d00642b204fff3fc9a07b720738e0
Services that declare that they can control magnification,
but never actually make a change or register a listener
waste cycles as we compute magnification data they never use.
Avoid registering for magnification callbacks unless magnification
gestures are enabled, a service is listening for magnification
changes, or a service has changed magnification.
Bug: 28425922
Change-Id: I114a833669bd53b2cd757c94ea52b65a2f838a08
We need to read the settings when UiAutomation closes in order to
configure other accessibility features from settings.
Bug: 28461805
Bug: 28460671
Change-Id: I030761922ec4acfa2d916e171c39e9dc2deb85a2
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
Clarifying region used for magnification as "magnificationRegion",
both in the public API and in the code. There's been significant
confusion about what "magnfifiedRegion" means. Removing
"availableRegion" from everywhere except where it's required, as
that region was identical to magnified/magnification region.
Trying to shut down magnification was a complex situation where
animations in progress and new magnification requests were tricky to
handle correctly. It was not possible to guarantee that the
magnification callbacks were unregistered consistently. There were
at least two situations that led to phone restarts:
1. If a triple tap was detected between unregistering the callbacks
and shutting down the input filter. In this case the magnification
request would go through.
2. If an animation had just started when magnification was turned
off, so the current magnification was 1.0 but the animator was
about to change it. In this case the callbacks would be unregistered,
and then the animator would start changing the magnification.
This change makes registering and unregistering magnification atomic.
It also makes MagnificationController stick around indefinitely once it
is created, registering and unregistering as needed to support
magnification gestures and services that control magnification. Services
that merely query the status of magnification no longer register for
callbacks.
One part of shutting down is turning off the animation and guaranteeing
that it won't try to make further changes. Adding a flag to
SpecAnimationBridge and a lock in that class so we can guarantee that
nothing happens when we aren't registered for magnification callbacks.
Also reconfiguring all accessibility options when a service stops to
make sure that only the features required by the current configuration
are enabled.
Bug: 27497138
Bug: 27821103
Change-Id: If697cbd34b117d82c8eee1ba7d0254089ee4241d
For M, we ignored device type entirely, but with ag/760625 we started
paying attention to it, which rejects events when keys from different
devices are pressed simultaneously. Since the volume keys show up as
different devices, the new behavior disrupted the event stream when
both volume keys were pressed.
Now tracking each device separately, which restores the old behavior
but still takes the device id into account. Holding down two keys
when enabling an accessibility service, however, always has and still
can produce an invalid event stream. It doesn't seem worth the
overhead, however, to track each key separately.
Bug: 28091773
Change-Id: I8d30de1f5e05f779b6fe305856d42f209ff8b038
