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
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
This API was using a oneway aidl call, which meant that the
service was disabled some time after the method returned. That
confused tests that were turning a service off during tearDown
and then turning it back on again in setUp.
Bug: 28621277
Change-Id: I75984df0613bdbb1bc876e2a15caf59106027337
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
Gestures now operate on the screen as the user sees it, so they are
affected by magnification. This makes gesture coordinates consistent
with the node bounds in screen and makes an eye or head tracking service
work much more easily.
Bug: 27747314
Change-Id: Idee60398d49d8c9af7405d974893c796b034c974
Add shell commands to check on current FBE status and system ready
status. Mark variables without first-class locking as volatile.
Fix bug where UI automation would crash while device was locked by
marking it as forced direct-boot aware.
Bug: 26498834
Change-Id: Ib4dfb9350925e5413f93a09baacf84c62f2ba0ea
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
Making changes requested by API review.
Also rethrowing all RemoveExceptions. Removing one exception thrown
when a service is called before it is connected since no other
method does that.
Bug: 27364143
Change-Id: I9b9b549552565802da36a735fd7e3ff2e148dc34
Encapsulating the logic to toggle multiwindow mode from recents,
and plumbing it through to accessibility global actions. Sending
accessibility events when windows bounds change. Exposing the
dock divider window type to accessibility services.
Bug: 27250995
Change-Id: Ib7491f1f853dc7f01bf5c5a4ac1f914f55d0608a
Look for both EA and non-EA accessibility services, but when the user
is locked only bind to EA services. Once the user is unlocked, we
take another pass and bind to any non-EA services.
We only consider disabling accessibility once the user is unlocked,
since there could be non-EA services waiting in the wings.
Bug: 25860579
Change-Id: I97bd019661457c3577d629ba12290d02f026011a
Closing two small holes in the implementation:
1. The gesture was dispatched before the callback was registered. It
was possible for gestures that failed quickly to fail to report any
status.
2. Gestures could be dispatched before the input filter was
installed. Adding a wait to give the filter a chance to install
before reporting a failure.
Also removing an unused method on the input filter.
Change-Id: I77cd80dcd2cec6c72b3761169aba5eaecf62250b
(cherry picked from commit 03465fb874)
Removed and updated some obsolete documentation about window
content. Stated the purpose of accessibility. Updated docs
for getTextSelection to include its ability to get cursor
position. Clarified wording for accessibility overlays.
Change-Id: Iaa11b499c2b7ece12ca182d336376d97b961b54f
Add public APIs to describe gestures and dispatch them from
an accessibility service. Added a new capability that
services must declare to have this capability.
Bug: 22514086
Change-Id: I9bff2d9335f0310115112d14b7ed033a6d6c2393
Send AccessibilityEvents to all accessibility services
that request them. No longer refuse to send them to
services with the same feedback type.
Change-Id: I137905c24fc75c075ab938175ecb6ea5f39112cf
Also separates magnification state and touch event handling. Moves
callbacks for window manager changes and display state changes into
the magnification controller.
Bug: 22718911
Change-Id: I3a8ba060a07d8f1f51856855a5f85601766fd45d
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
An accessibility service may register to observe the interactive windows
on the primary display. These windows are the one that has input focus and
ones a sighted user can touch. It is sometimes beneficial for an
accessibility service to overlay a window to intercept user interaction
and based on that introspect and perform an action on the windows that
are on the screen. This is problematic as overlaying a full screen window
that is touchable prevents the accessibility service to introspect the
content under this window.
This change adds a special type of window that only an accessibility service
can place which does not affect what an accessibility service can "see" on
the screen. Hence, even putting such a window full screen the service will
be able to interact with the other interactive windows it covers.
Change-Id: I053ccc3a5c6360a98dc40bdb172b54dab35d8b31
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
We are caching the window data in the accessibility service process.
When windows change we were sending the dalta of the windows the
service knows about. To make this work when the app asked for all
windows we had to call into the system as new windows may have
appeared. This was slow.
Now we are telling the service some windows change and if it gets
the windows we cache them. We call into the system only on a cache
miss and evict all windows from the cache on window change event.
We do not evict the nodes of the window as the former may have
just moved. If views in a window change they fire accessibility
events that trigger the correct eviction.
Change-Id: I586a72a2497b0d44a75288fa758e7e88817f3300
Also fixes an infinite recursion bug in the WindowManagerService
implementation of WindowManagerInternal.
BUG: 16129909
Change-Id: I4f9d32f4e6c3ad460652c5e5271540fa5032a1f5
1. The APIs for introspecting interactive windows were reporting only
the touchable windows but were missing the focused window. The user
can interact with the latter by typing, hence it should always be
reported. Also this was breaking backwards compatibility as if the
focused window is covered by a modal one, the focused window was not
reporeted and this was putting the active window in a bad state as
the latter is either the focused window or the one the user is touching.
2. Window change events are too frequent as on window transition things
are chanign a lot. Now we are trottling the windows changed events
at the standard recurring accessibility event interval.
3. Fixed a wrong flag comparison and removed some unneded code.
buy:15434666
bug:15432989
Change-Id: I825b33067e8cbf26396a4d38642bde4907b6427a
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
1. The old introspection model was allowing querying only the active window
which is the one the user is touching or the focused one if no window is
touched. This was limiting as auto completion drop downs were not inspectable,
there was not way to know when the IME toggles, non-focusable windows were
not inspectable if the user taps them as until a screen-reader starts
introspecting the users finger is up, accessibility focus was limited to
only one window and the user couldn't use gestures to visit the whole UI,
and other things I can't remember right now.
The new APIs allow getting all interactive windows, i.e. ones that a
sighted user can interact with. This prevents an accessibility service
from interacting with content a sighter user cannot. The list of windows
can be obtained from an accessibility service or the host window from an
accessibility node info. Introspecting windows obey the same rules for
introspecting node, i.e. the service has to declare this capability
in its manifest.
When some windows change accessibility services receive a new type
of event. Initially the types of windows is very limited. We provide
the bounds in screen, layer, and some other properties which are
enough for a client to determined the spacial and hierarchical
relationship of the windows.
2. Update the documentation in AccessibilityService for newer event types.
3. LongArray was not removing elements properly.
4. Composite accessibility node ids were not properly constructed as they
are composed of two ints, each taking 32 bits. However, the values for
undefined were -1 so composing a 64 long from -1, -1 prevents from getting
back these values when unpacking.
5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added
a check that enforces such trees to be well formed on dev builds.
6. Removed an necessary code for piping the touch exploration state to
the policy as it should just use the AccessibilityManager from context.
7. When view's visibility changed it was not firing an event to notify
clients it disappeared/appeared. Also ViewGroup was sending accessibility
events for changes if the view is included for accessibility but this is
wrong as there may be a service that want all nodes, hence events from them.
The accessibility manager service takes care of delivering events from
not important for accessibility nodes only to services that want such.
8. Several places were asking for prefetching of sibling but not predecessor
nodes which resulted in prefetching of unconnected subtrees.
9. The local AccessibilityManager implementation was relying on the backing
service being ready when it is created but it can be fetched from a context
before that. If that happens the local manager was in a broken state forever.
Now it is more robust and starts working properly once the backing service
is up. Several places were lacking locking.
bug:13331285
Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
Since older versions of the platform will crash if the mode is
set to 3, this CL adds an extra bit and uses 4 as the mode. This
will also cleanly default the mode to AUTO on unsupported
platforms.
BUG: 11031947
Change-Id: I48035abbf35523d65cead6f27be10f8087973ceb
Since the enable touch exploration capability is dynamically granted by
the user for apps targeting pre-JellybeanMR2 API level, we have to properly
update the accessibility service info for that service and also avoid
caching copies of the service info.
bug:8633951
Change-Id: I83dd1c852706ec55d40cda7209ad842889fb970a
1. UiAutomation#executeAndWaitForEvent method was invoking the passed
runnable while holding the lock which may lead to a deadlock. For
example: a runnable that calls getActivity() gets us into a state
like this.
2. UI automation services did not get all capabilities such a
service can have. Now a UI test service gets all of them.
3. When UiAutomation was exiting for event fired as a result of a
performed action, it was checking whether the received evnet time
is strictly before the time of executing the command that should
fire the event. However, if the execution is fast enough, i.e.
less than one millisecond, then the event time and the execution
time are the same. This was leading to a missed signal in rare
cases.
4. AccessibilityNodeInfoCache was not clearing the relevant state
for accessibility focus clearing event.
5. Accessibility text traversal in TextView was partially using text
and partially content description - broken. Now we are using the
text since for text view and content desc for other views. In other
words, we are using the most precise text we have.
6. AccessibilityManagerService was not granting capabilities of a
UiAutomation service - plainly wrong.
CTS change:https://googleplex-android-review.googlesource.com/#/c/300693/
bug:8695422
bug:8657560
Change-Id: I9afc5c3c69eb51f1c01930959232f44681b15e86
Accessibility services can perform special operations such as retrieve
the screen content, enable explore by touch, etc. To ensure the user
is aware that the service will perform special operations we were using
permissions. However, the special operations cannot be performed unless
the service is really enabled by the user and it is at this point that
we want to notify the user about the service capabilities.
This change adds capability attributes to the accessibility service's
meta-data XML file. The service has to declare the capability and when
it is enabled we show the user the capabilities in the warining dialog.
bug:8633951
Change-Id: Id3442dc71dad018e606888afdc40834682fdb037
Now that we have gestures which are detected by the system and
interpreted by an accessibility service, there is an inconsistent
behavior between using the gestures and the keyboard. Some devices
have both. Therefore, an accessibility service should be able to
interpret keys in addition to gestures to provide consistent user
experience. Now an accessibility service can expose shortcuts for
each gestural action.
This change adds APIs for an accessibility service to observe and
intercept at will key events before they are dispatched to the
rest of the system. The service can return true or false from its
onKeyEvent to either consume the event or to let it be delivered
to the rest of the system. However, the service will *not* be
able to inject key events or modify the observed ones.
Previous ideas of allowing the service to say it "tracks" the event
so the latter is not delivered to the system until a subsequent
event is either "handled" or "not handled" will not work. If the
service tracks a key but no other key is pressed essentially this
key is not delivered to the app and at potentially much later point
this stashed event will be delivered in maybe a completely different
context.The correct way of implementing shortcuts is a combination
of modifier keys plus some other key/key sequence. Key events already
contain information about which modifier keys are down as well as
the service can track them as well.
bug:8088812
Change-Id: I81ba9a7de9f19ca6662661f27fdc852323e38c00
1. Accessibility service may set a flag to request a compressed
view of the node tree representing the screen. The compressed
state does not contain nodes that do to react to user actions
and do not draw content, i.e. they are dumb view managers. This
compressed hierarchy was very beneficial to the test team and
this change is exposing the APIs. The compression has to be
configurable since old tests are written against uncompressed
view tree. Basically we do not hide the fact that UIAutomation
is simply an accessibility service with some other useful APIs.
bug:8051095
2. Accessibility service can perform global actions such as opening
notifications, opening recent apps, etc. These are also needed
for UI testing since there is no other way to do it via the
existing UIAutomation APIs. Basically we do not hide the fact
that UIAutomation is simply an accessibility service with some
other useful APIs.
bug:8117582
Change-Id: I7b6e24b5f7a973fdada0cc199cff9f882b10720b
1. The accessibility manager service updates its internal state
based on which settings are enabled, what accessibility services
are installed and what features are requested by the enabled
services. It was trying to do the minimal amount of work to
react to contextual changes like these which resulted in missed
cases and complex code. Now there is a single method that reads
the contextual information and single method that reacts to
contextual changes. This makes the code much easier to maintain.
2. The accessibility manager service was not updating its internal
state when requested features from accessibility services change.
It was relying on changing system settings and reacting to the
settings change. This is problematic since the internal state is
not updated atomically which leads to race condition bugs. For
example, if touch exploration is enabled and a service requests
it is disabled, the internal state will not be updated but a
request for a settings change will be made. Now while the settings
change is propagating another request form the same service
comes to enable touch exploration but the system incorrectly
thinks touch exploration is enabled. At the end the feature is
disabled even though it was requested.
3. Fixed a potential NPE if the accessibility input filter's event
handler was nullified between processing two event batches.
4. Fixed a bug where, if magnification is enabled, it does not work
on the settings screen since the magnified bounds are not pushed
from the window manager to the accessibility manager.
Change-Id: Idf629a06480e12f0d88372762df6c024fe0d7856
