History log of /frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
e45c0b230ba92d7daf8bf625a59bd87d5948101b 09-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Crash in the touch explorer.

1. The touch explorer was notified for accessibility events from
a binder thread which was poking the internal state of the
latter which by design is not tread safe. Since the touch
explorer is expected to be running only on the main thread
the accessibility manager service delivers the accessibility
events to the explorer on that thread.

bug:6635496

Change-Id: Ifdc5329e4be8e485d7f77f0fb472184494fa0d15
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
385d9f24b5ce2acb86c0dc192ce702718ab01c39 08-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Cannot click on the last touch explored auto-completion item.

1. When typing into an auto completion edit field a list of completions pops up and if
the user touch explores the list and tries to double tap to select the touched
completion the latter is not selected.

The auto completion is a popup that does not take input focus and is overlaid on
top of the window that has input focus. The touch explorer was clicking on the
location of the accessibility focus if the last touch explored location is within
the bounds of the active window. In this case this was the window with the edit
text into which the user is typing. The check performed by the touch explorer
was missing the case when the last touch explored location was within the bounds
of the active window but it actually was deloverd to another overlaid window.
Now we are poking on the accessibility focus location if the last explored
location is within the active window and was delivered to it.

bug:6629535

Change-Id: Ie66d5bb81ab021f2bb0414339b7de26d96826191
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
86783474fdec98a22bc22e224462767eab13e273 07-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Cannot interact with dialogs when IME is up and on not touch explored popups.

1. If the last touch explored location is within the active window we
used to click on exact location if it is within the accessibility
focus otherwise in the accessibility focus center. If the last touch
explored location is not within the active window we used to just
click there. This breaks in the case were one has touch explored
at a given place in the current window and now a dialog opens *not*
covering the touch explored location. If one uses swipes to move
accessibility focus i.e. to traverse the dialog without touching
it one cannot activate anything because the touch explorer is using
the last touch explored location that is outside of the active
window e.g the dialog.

The solution is to clear the last touch explored location when a
window opens or accessibility focus moves. If the last touch
explored location is null we are clicking in the accessibility
focus location.

bug:6620911

2. There is a bug in the window manager that does not notify a
window that its location has changed (bug:6623031). This breaks
accessibility interaction with dialogs that have input because
when the IME is up the dialog is moved but not notified. Now
the accessibility layer gets incorrect location for the
accessibility focus and the window bounds.

The soluion is when the accessibility manager service calls
into the remove thress to obtain some accessibility node infos
it passes the window left and top which it gets from the
window manager. These values are used to update the attach info
window left and top so all accessibility node infos emitted
from that window had correct bounds in screen coordinates.

bug:6620796

Change-Id: I18914f2095c55cfc826acf5277bd94b776bda0c8
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
ccf97dc1afc1b0f99ced0b5324e383edd5ee8246 05-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Merge "Global accessibility action to open recent apps shows the old dialog style." into jb-dev
c682fc965df2518a95d23e39ec51d788100d20ec 04-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Global accessibility action to open recent apps shows the old dialog style.

1. The global action to open recent apps shows the old dialog style rent apps
panel. Apparently the key code to open recent apps is not opening the new
UI so the AccessibilityManagerService is calling directly the method on
the IStatusBarSerivce to do so.

bug:6607664

Change-Id: I94c1963b07947776bf1c2448903b26f3603f9a59
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
cd94caf2bb94f07522ea5bbf0e37dea960b38220 04-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Touch exploration gesture end not delivered to clients.

1. Touch exploration gestures are demarcated by start and end
events. Due to a bug in the AccessibilityManagerService
the gesture end event was not dispatched. This caused the
AccessibilityNodeInfoCache to be off sync since it relies
on getting such events not to mention that the clients were
not getting the end but only the start event. The issue
was that the notified service types variable was not reset
after every event so when the manager sends the last hover
exit it flags that the service type is already notified
resulting in dropping on the floor the following gesture
end event.

bug:6539306

Change-Id: I2b96bcecea3b2240199d67f01afa6a033afce1de
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
9a4c5cd19106c3021eeead27fbc2aa05ad7d0d18 30-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Ask to enable touch exploration only the first time it enables the feature.

1. Now we are asking the user to grant permission to the service to enable
touch exploration only the first time this service is enabled. If the
service was uninstalled and then later installed we ask the user again.
This avoids the scenario in which rebooting the device or upgrading an
accessibility service leaves the device in a state in which the user
cannot interact with.

bug:6582088

Change-Id: I51d24e4892b3b48c9fb11dfb09ec1118502ba526
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
4074e8a3f429f62aff3312083d1d925d794ffacc 23-May-2012 Svetoslav Ganov <svetoslavganov@google.com> System accessibility state update postponed if UI test autmation is running.

1. If a UI test automation accessibility service is connected to the
system we pospone state updates in the AccessibilityManagerService
for the moment the UI automations service dies or is disconnected.

bug:6540522

Change-Id: I48ddf603b53d2158a00edcf8ad05cfe2575d4d75
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
64a03875897afe07b731eaf66969e87362a1a740 23-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Merge "Perform an action in AccessibilityManagerSerivce using wrong process id." into jb-dev
9bf21873c900e7bf82d864172ab40527a48dae3e 23-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Perform an action in AccessibilityManagerSerivce using wrong process id.

1. We are passing the interrogating process id in the remote
accessibility requests to catch the query from the same
thread. While all other methods were doing this correctly
somehow the perform action is using the incorrect process id.

bug:6534935

Change-Id: Icef50833903c562758d51ef316b60c53c7a336c0
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
ec2c1717780fa4f61ed11dced16a87b8ae5d7fb0 22-May-2012 Svetoslav Ganov <svetoslavganov@google.com> UI test automation not working.

1. The internal service instance created by AccessibilityManagerService
was getting the looper of the current thread when created. This works
for real accessibility services but since UI automation service is
registered via an IPC the binder thread has no looper. Now we explicitly
get the correct looper.

bug:6535435

Change-Id: I63a2ada1b65c4b3c71c3d1e6deb3dfdeb7a3d6d6
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
e15ccb93add99ebb9cd7aec03a04faa37f45b39d 17-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Changing the interaction model of the touch explorer.

1. Now the user have to double tap to activate the last
item. If the last touched window is not active because
it does not take input focus the click on the last
touch explored location. Othewise the click is on the
accessibility focus location.

bug:5932640

Change-Id: Ibb7b97262a7c5f2f94abef429e02790fdc91a8dd
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
53e184d34e7c5b1a65c74fac55f9a635d8131dda 17-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Accessibility service needs to request permission to be bound to.

1. Every accessibility services targeting JellyBean or higher has
to request a special permission for the system to bind to it.

Change-Id: I6e579326bdf3597f148d6c67317455701ec8af68
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
5c89f44ea16667bf18297ccb9fb10aad639dab1f 15-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Implement the global accessibility action to expand notifications.

bug:6468852

Change-Id: Id4494a07b1ed96773e22dcfdd5991afe3ee98004
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
11fd02f63acba18a1b03351b595490597136fc6a 14-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Merge "Update the API version checks." into jb-dev
5a48f9758b990fe6c46359927a40aecb6a02b64c 13-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Update the API version checks.

1. Since the API version has been finalized this change
updates the SDk version checks to use the JellyBean
verson number.

bug:5947249

Change-Id: Ie22fa7e18a7ea7b0c7077d80246a26c17f327ceb
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
7b1e0c7046abefc0b40884b36197c8a803d9cf6d 13-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Removing default accessibility gesture handling.

1. The initial design was to have some accessibility gestures
being handled by the system if the gesture handling access
service does not consume the gesture. However, we are not
sure what a good default is and once we add a default handler
we cannot remove it since people may rely on it. Thus, we
take the simples approach and let the accessibility service
handle the gestures. If no gestures are handled the system
will work in explore by touch as before.

bug:5932640

Change-Id: I865a83549fa03b0141d27ce9713e9b7bb45a57b4
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
a1dc761c8322355eb1bb71d3d6c9c603c1d1fc0f 10-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding scroll actions to accessibility node info.

1. Scrolling actions are crucial for enabling a gesture based
traversal of the UI and specifically scrollable containers
especially lists and anything backed by an adapter. Since
accessibility focus can land only attached views, it cannot
visit views for adapter items not shown on the screen.
Auto scrolling the list as a result of putting access focus
ot a list item does not work well since the user may get
trapped in a long list. Adding an accessibility node provider
to emit virtual views for one view before the first and one
after the last is complex and suffers the limitation of trapping
the user. Accessibility service need an explicit scroll actions
which may be performed upon an explicit user action. Hence,
the user is informed for the start/end of the visible part of
the list and he makes a deliberate choice to scroll. This will
benefit also people developing Braille devices since they can
scroll the content without telling the user to stop using the
Braille controller and take the device out of his pocket to scroll
and go back to the Braille controller.

NOTE: Without these action large portions of the screen will be
hard to access since users will have to touch and explore to
find and scroll the list.

Change-Id: Iafcf54d4967893205872b3649025a4e347a299ed
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
e4abc512aa6474f0106f407f7b399832da34483f 09-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Remove activation gestures form reported and add a touch explore requesting flag.

1. Delegating activation gestures has several issues that we should
decide how to handle if possible before allowing an accessibility
service to take over them:

A) It is needed that every view than can be clicked or long pressed on
reacts to such as a response to calling performClick and performLongPress
which is not necessary true since the view may watch the touch
events and do its own click long click detection. As a result it may
be possible that there are view a user cannot interact with in
touch exploration mode but can if not in that mode.

B) Clicking or long pressing on a different location in a view may yield
different results, for example NumberPicker. Ideally such views have
to implement AccessibilityNodeProvide which provider handles correctly
the request for click long press on virtual nodes. Some apps however
just fire different hover accessibility events when the user is over
a specific semantic portion of the view but do not provide virtual
nodes. Hence, a user will not be able to interact with such semantic
regions but the system can achieve that by sending the click/long click
at the precise location in the view that was last touch explored.

2. Adding a flag on accessibility service info to request explore by touch
mode. There is no need to put the device in this mode if node of the currently
enabled accessibility services supports it. Now the problem is inverted and
the service has to explicitly state its capability.

3. Fixing a bug where includeImportantViews was ignored for automation
services.

Change-Id: I3b29a19f24ab5e26ee29f974bbac2197614c9e2a
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
df549f83810c6fa76be1845363ef69809a30e569 09-May-2012 Guang Zhu <guangzhu@google.com> Make UiTestAutomationBridge see non-important views again

This problem was introduced in I74df9c24. The intention of the
change was still let UiTestAutomationBridge see the
non-important views, but there were bugs in the implementation:

1. AccessibilityManagerService was not really updating
mIncludeNotImportantViews when mIsAutomation is true

2. Wrong constant is used to set the flag

Change-Id: Ia0a2e9ed9720bd0ea3a563e0b492e870a6ec1586
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
ef5889810c32eca9d874503fdc7df6e2a1575993 08-May-2012 Svetoslav Ganov <svetoslavganov@google.com> DefaultGestureHandlingHelperService should not include non-important views.

1. Since we are using a stateless proxy accessibility service to
perform default accessibility gesture handling it shuld not
operate against not important views.

bug:6422069

Change-Id: I74df9c2415ab3b164d9ac5873f7004c0459e2bfa
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
2b435aada3d274a9c08d334946fff1ab9ba15b48 05-May-2012 Svetoslav Ganov <svetoslavganov@google.com> API REVIEW: android.view.accessibility

1. Changed all references to granularity to movement
granularity. BTW, to be more precise it should be
text movement granularity.

bug:6435232

Change-Id: If6366b002ca3390f74918995b342baff2cbcfd01
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
5a00661bd6a1bfe82656c51d23a3ac6be99602a2 02-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Accessibility focus should not affect the currently active window.

1. The event of setting an accessibility focus on a view should not
make the host window the currently active one.

bug:6400648

Change-Id: Ib45c255f441c38489ee9d4ab5f284550ac5f6b01
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
afe8cf2623f6e28e2c2bf350173e66718b5aa4c0 28-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Removing action arguments checks.

1. The checks for action arguments are not needed since they
may cause trouble for developers if we add more args to
an action.

bug:6414006

Change-Id: Ia4212b52be183b1ef1cfd2561ce618cef2b015e4
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
b7ff3255c6d4e12f9d2334e3bbec0a125b7b09dc 25-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding explicit text traversal granularities and actions for web navigation.

1. The granularities for traversing the text content of an accessibility
node info are now predefined constants and custom ones will not be
supported. This is the simplest solution - we can always add namespaced
user defined ones (unlikely).

2. Added actions for traversing web content. These actions can be used by
an accessibility service to transparently drive the JavaScript based
screen reader that is used for handling web content.

3. Added a new accessibility event type for traversing the content of a
view. This event is needed to announce to the user what is the next
element, i.e. the one next to the cursor, after the view's text was
traversed.

bug:5932640
bug:6389591

Change-Id: I144647da55bc4005c64f89865ef333af8359e145
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
76f287e416ded85734b610f316e38d243d2ddb09 23-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Removing hierarchical accessibility focus directions.

1. The accessibility focus directions are not needed since an
accessibility service just get the root, first child, next
sibling, previous sibling and call execute the action to
give it accessibility focus. Now the accessibility node
info tree is properly ordered taking into account layout
manager directions for both layout manager that we report
and ones that we have determined as not important for
accessibility. Also the position of a node info are ordered
properly based on their coordinates after all transformations
as opposed to child index.

bug:5932640

Change-Id: I994a8297cb1e57c829ecbac73a937c2bcbe0bac7
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
122b2c32dea573a3efbd0d608a70b7cd169d99dd 21-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Fixing a couple of issues I have introduces in the last patch.

1. Fix waiting for the wrong instance.

2. Fix cloning of accessibility node info.

Change-Id: Icabf0d4bc947602a32fddc6642cc787f2bc766e4
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
72de2062485f711c9a2291c204fd2c0fb6c4e20f 21-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Merge "Adding support for traversing the content of a node info at granularity."
aa780c110922148a6a4ba06734bb2b0bb8c98f93 20-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding support for traversing the content of a node info at granularity.

1. A view that creates an accessibility node info may add to the info
a list of granularity labels. These are granularities by which the
source view can iterate over its content. For example a text view
may support character, word link while a web view may additionally
support buttons, tables, etc. There are actions on accessibility
node info to go to the next/previous at a given granularity which
is passesed as an argument.

2. Added Bundle argument to the APIs for performing accessibility
actions. This is generic and extensible.

bug:5932640

Change-Id: I328cbbb4cddfdee082ab2a8b7ff1bd7477d8d6f9
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
8e2f41426ce162a164d1074dd67ea4549ffd0711 20-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Fixes in the accessibility gesture dispatching.

1. The gesture dispatcher thread was not waiting in a loop
that check for complete initialization. Therefore is was
susceptible to missed signals and unexpected interrupts.

2. In the gesture processing message handle the interaction id
was reading the wrong message argument.

bug:5932640

Change-Id: Ic65ecc01a7fe7d43929c6c07d0759ae9001cf515
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
e1a996e99dc68b48efad989876c01ce05a7a58ac 20-Apr-2012 Dianne Hackborn <hackbod@google.com> Merge "Move handling of package changes to a background thread."
d0d7503fd3e941113094532f28986f49b11b5fdb 20-Apr-2012 Dianne Hackborn <hackbod@google.com> Move handling of package changes to a background thread.

Helps get rid of some jank when installing applications.

Change-Id: I97d0022f82d67796e334d37086e5911dd6ca6b62
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
fefd20e927b7252d63acb7bb1852c5188e3c1b2e 20-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding an opt-in mechanism for gesture detection in AccessibilityService.

1. An accessibility service has to explicitly opt in to be notified
for gestures by the system. There is only one accessibility service
that handles gestures and in case it does not handle a gesture
the system performs default handling. This default handling ensures
that we have gesture navigation even if no accessibility service
would like to participate/customize the interaction model.

bug:5932640

Change-Id: Id8194293bd94097b455e9388b68134a45dc3b8fa
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
005b83b0c62d3d0538f0d566b08bd457015ec661 17-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding some more gestures and actions for accessibility.

1. Added more gesture for accessibility. After a meeting
with the access-eng team we have decided that the current
set of gestures may be smaller than needed considering
that we will use four gestures for home, back, recents,
and notifications.

2. Adding actions for going back, home, opening the recents,
and opening the notifications.

3. Added preliminary mapping from some of the new gestures
to the new actions.

4. Fixed a bug in the accessibility interaction controller
which was trying to create a handled on the main looper
thread which may be null if the queried UI is in the
system process. Now the context looper of the root view
is used.

5. Fixed a bug of using an incorrect constant.

6. Added a missing locking in a couple of places.

7. Fixed view comparison for accessibilityt since it was
not anisymmetric.

bug:5932640
bug:5605641

Change-Id: Icc983bf4eafefa42b65920b3782ed8a25518e94f
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
31725b3f387dacf018804e3c500d693261f1d994 17-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Fixing a regression I have introduced.

bug:6344558

Change-Id: Ie726e091942e337962baa052953002be724068b1
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
4213804541a8b05cd0587b138a2fd9a3b7fd9350 20-Mar-2012 Svetoslav Ganov <svetoslavganov@google.com> Accessibility focus - framework

Usefulness: Keep track of the current user location in the screen when
traversing the it. Enabling structural and directional
navigation over all elements on the screen. This enables
blind users that know the application layout to efficiently
locate desired elements as opposed to try touch exploring the
region where the the element should be - very tedious.

Rationale: There are two ways to implement accessibility focus One is
to let accessibility services keep track of it since they
have access to the screen content, and another to let the view
hierarchy keep track of it. While the first approach would
require almost no work on our part it poses several challenges
which make it a sub-optimal choice. Having the accessibility focus
in the accessibility service would require that service to scrape
the window content every time it changes to sync the view tree
state and the accessibility focus location. Pretty much the service
will have to keep an off screen model of the screen content. This
could be quite challenging to get right and would incur performance
cost for the multiple IPCs to repeatedly fetch the screen content.
Further, keeping virtual accessibility focus (i.e. in the service)
would require sync of the input and accessibility focus. This could
be challenging to implement right as well. Also, having an unlimited
number of accessibility services we cannot guarantee that they will
have a proper implementation, if any, to allow users to perform structural
navigation of the screen content. Assuming two accessibility
services implement structural navigation via accessibility focus,
there is not guarantee that they will behave similarly by default,
i.e. provide some standard way to navigate the screen content.
Also feedback from experienced accessibility researchers, specifically
T.V Raman, provides evidence that having virtual accessibility focus
creates many issues and it is very hard to get right.
Therefore, keeping accessibility focus in the system will avoid
keeping an off-screen model in accessibility services, it will always
be in sync with the state of the view hierarchy and the input focus.
Also this will allow having a default behavior for traversing the
screen via this accessibility focus that is consistent in all
accessibility services. We provide accessibility services with APIs to
override this behavior but all of them will perform screen traversal
in a consistent way by default.

Behavior: If accessibility is enabled the accessibility focus is the leading one
and the input follows it. Putting accessibility focus on a view moves
the input focus there. Clearing the accessibility focus of a view, clears
the input focus of this view. If accessibility focus is on a view that
cannot take input focus, then no other view should have input focus.
In accessibility mode we initially give accessibility focus to the topmost
view and no view has input focus. This ensures consistent behavior accross
all apps. Note that accessibility focus can move hierarchically in the
view tree and having it at the root is better than putting it where the
input focus would be - at the first input focusable which could be at
an arbitrary depth in the view tree. By default not all views are reported
for accessibility, only the important ones. A view may be explicitly labeled
as important or not for accessibility, or the system determines which one
is such - default. Important views for accessibility are all views that are
not dumb layout managers used only to arrange their chidren. Since the same
content arrangement can be obtained via different combintation of layout
managers, such managers cannot be used to reliably determine the application
structure. For example, a user should see a list as a list view with several
list items and each list item as a text view and a button as opposed to seeing
all the layout managers used to arrange the list item's content.
By default only important for accessibility views are regared for accessibility
purposes. View not regarded for accessibility neither fire accessibility events,
nor are reported being on the screen. An accessibility service may request the
system to regard all views. If the target SDK of an accessibility services is
less than JellyBean, then all views are regarded for accessibility.
Note that an accessibility service that requires all view to be ragarded for
accessibility may put accessibility focus on any view. Hence, it may implement
any navigational paradigm if desired. Especially considering the fact that
the system is detecting some standard gestures and delegates their processing
to an accessibility service. The default implementation of an accessibility
services performs the defualt navigation.

bug:5932640
bug:5605641

Change-Id: Ieac461d480579d706a847b9325720cb254736ebe
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
57c7fd5a43237afc5e8ef31a076e862c0c16c328 24-Feb-2012 Svetoslav Ganov <svetoslavganov@google.com> Fixing issues with the AccessibilityNodeInfo cache.

1. Before there were two caches one in the app process that
kept track only the ids of infos that were given to a
querying client and one in the querying client that
holds the infos. This design requires precise sync
between the caches. Doing that is somehow complicated
since the app has cache for each window and it has
to intercept all accessibility events from that window
to manage the cache. Each app has to have a cache for
each querying client. This approach would guarantee that
no infos are fetched twice but due to its stateful nature
and the two caches is tricky to implement and adds
unnecessary complexity. Now there is only one cache in
the client and the apps are stateless. The client is
passing flags to the app that are a clue what nodes to
prefetch. This approach may occasionally fetch a node
twice but it is considerably simpler and stateless
from the app perspective - there is only one cache.
Fetching a node more than once does not cause much
overhead compared to the IPC.

Change-Id: Ia02f6fe4f82cff9a9c2e21f4a36747de0f414c6f
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
0d04e245534cf777dfaf16dce3c51553837c14ff 21-Feb-2012 Svetoslav Ganov <svetoslavganov@google.com> Improving accessibility APIs used for UI automation.

1. UiTestAutomationBridge was accessing the root node in the
active window by tracking the accessibility event stream
and keeping the last active window changing event. Now
the bridge is stateless and the root node is fetched by
passing special window and view id with the request to
the system.

2. AccessibilityNodeInfos that are cached were not finished,
i.e. not sealed, causing exception when trying to access
their children or rpedecessors.

3. AccessibilityManagerService was not properly restoring its
state after the UI automation bridge disconnects from it.
I particular the devices was still in explore by touch mode
event if no services are enabled and the sutomation bridge
is disconnected.

4. ViewRootImpl for the focused window now fires accessibility
events when accessibility is enabled to allow accessibility
services to determine the current user location.

5. Several missing null checks in ViewRootImpl are fixed since
there were scenraios in which a NPE can occur.

6. Update the internal window content querying tests.

7. ViewRootImpl was firing one extra focus event.
bug:6009813
bug:6026952

Change-Id: Ib2e058d64538ecc268f9ef7a8f36ead047868a05
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
9b666d0faadd26827ca5b7cf6af3aa94af6adcd9 10-Feb-2012 Svetoslav Ganov <svetoslavganov@google.com> UI automation service disconnected upon package change.

1. The AccessibilityManagerService used to disable the IU
automation service on package change. This behavior
was incorrect since the automation service has to
survive package installations.

bug:5975207

Change-Id: Idb5e76d02625c333a5842a6b5c5bc90c9b9634c9
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
79311c4af8b54d3cd47ab37a120c648bfc990511 18-Jan-2012 Svetoslav Ganov <svetoslavganov@google.com> Speedup the accessibility window querying APIs and clean up.

1. Now when an interrogating client requires an AccessibilibtyNodeInfo
we aggressively prefetch all the predecessors of that node and its
descendants. The number of fetched nodes in one call is limited to
keep the APIs responsive. The prefetched nodes infos are cached in
the client process. The node info cache is invalidated partially or
completely based on the fired accessibility events. For example,
TYPE_WINDOW_STATE_CHANGED event clears the cache while
TYPE_VIEW_FOCUSED removed the focused node from the cache, etc.
Note that the cache is only for the currently active window.
The ViewRootImple also keeps track of only the ids of the node
infos it has sent to each querying process to avoid duplicating
work. Usually only one process will query the screen content
but we support the general case. Also all the caches are
automatically invalidated so not additional bookkeeping is
required. This simple strategy leads to 10X improving the
speed of the querying APIs.

2. The Monkey and UI test automation framework were registering a
raw event listener for accessibility events and hence perform
connection and cache management in similar way to an AccessibilityService.
This is fragile and requires the implementer to know internal framework
stuff. Now the functionality required by the Monkey and the UI automation
is encapsulated in a new UiTestAutomationBridge class. To enable this
was requited some refactoring of AccessibilityService.

3. Removed the *doSomethiong*InActiveWindow methods from the
AccessibilityInteractionClient and the AccessibilityInteractionConnection.
The function of these methods is implemented by the not *InActiveWindow
version while passing appropriate constants.

4. Updated the internal window Querying tests to use the new
UiTestAutomationBridge.

5. If the ViewRootImple was not initialized the querying APIs of
the IAccessibilityInteractionConnection implementation were
returning immediately without calling the callback with null.
This was causing the client side to wait until it times out. Now
the client is notified as soon as the call fails.

6. Added a check to guarantee that Views with AccessibilityNodeProvider
do not have children.

bug:5879530

Change-Id: I3ee43718748fec6e570992c7073c8f6f1fc269b3
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
f3b4f3163b5b4c0a54a2643f07c97c47b14a1eb7 01-Dec-2011 Svetoslav Ganov <svetoslavganov@google.com> resolved conflicts for merge of 26f7a81f to master

Change-Id: I6bf5fd7c0de7945cef84602dbe3a7bbed587700f
d116d7c78a9c53f30a73bf273bd7618312cf3847 22-Nov-2011 Svetoslav Ganov <svetoslavganov@google.com> Fixing memory leaks in the accessiiblity layer.

1. AccessibilityInteractionConnections were removed from the
AccessiiblityManagerService but their DeathRecipents were
not unregistered, thus every removed interaction connection
was essentially leaking. Such connection is registered in
the system for every ViewRootImpl when accessiiblity is
enabled and inregistered when disabled.

2. Every AccessibilityEvent and AccessiilbityEventInfo obtained
from a widnow content querying accessibility service had a
handle to a binder proxy over which to make queries. Hoewever,
holding a proxy to a remote binder prevents the latter from
being garbage collected. Therefore, now the events and infos
have a connection id insteand and the hindden singleton
AccessiiblityInteaction client via which queries are made
has a registry with the connections. This class looks up
the connection given its id before making an IPC. Now the
connection is stored in one place and when an accessibility
service is disconnected the system sets the connection to
null so the binder object in the system process can be GCed.
Note that before this change a bad implemented accessibility
service could cache events or infos causing a leak in the
system process. This should never happen.

3. SparseArray was not clearing the reference to the last moved
element while garbage collecting thus causing a leak.

bug:5664337

Change-Id: Id397f614b026d43bd7b57bb7f8186bca5cdfcff9
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
021078554b902179442a345a9d080a165c3b5139 04-Oct-2011 Svetoslav Ganov <svetoslavganov@google.com> Adding APIs to enable reporting virtual view hierarchies to accessibility serivces.

Added an interface that is the contract for a client to expose a virtual
view hierarchy to accessibility services. Clients impement this interface
and set it in the View that is the root of the virtual sub-tree. Adding
this finctionality via compostion as opposed to inheritance enables apps
to maintain backwards compatibility by setting the accessibility virtual
hierarchy provider on the View only if the API version is high enough.

bug:5382859

Change-Id: I7e3927b71a5517943c6cb071be2e87fba23132bf
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
b6eca6e6691d4563d8395b3c3843d9932a2a6560 27-Sep-2011 Svetoslav Ganov <svetoslavganov@google.com> Accessibility test automation API not working.

1. Due to a previous change that disabled accessibility if not enabled
and installed serivces are present the automation APIs stopped working
since they use fake automation service that is not installed.

2. Added clean up of death recipients when binders die.

bug:5374662
bug:5239044

Change-Id: I1f3c8cd1d1c79753a4a64e2b8b2963025abb2939
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
1e741b2705023be64389ac3e31c5f63d330470a5 21-Sep-2011 Svetoslav Ganov <svetoslavganov@google.com> System not checking if enabled services are installed when disabling accessibility.

The system is didabling accessiblity if no accessibility serivces are enabled
to avoid sending events across processes if no recipients are present. The
check considers enabled services which may not have been installed. Now the
check is made against enabled and installed serivces.

bug:5347273

Change-Id: Iad391a1a5bf0bbca470584bc8392f35821ba768c
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
ea515aeafa01de6f50c854ee381b972ef2478284 15-Sep-2011 Svetoslav Ganov <svetoslavganov@google.com> Update the public APIs for finding views by text to optionally use content description.

1. Added flags to the search method to specify whether to match text or
content description or both.

2. Added test case for the seach by content description.

3. Updated the code in AccessibilityManager service to reflect the latest
changes there so test automation service works - this is the fake
service used for UI automation.

Change-Id: I14a6779a920ff0430e78947ea5aaf876c2e66076
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
d07d60b9bc0fd2e88f58d6e68dbfadad1bdd31cf 14-Sep-2011 Svetoslav Ganov <svetoslavganov@google.com> AccessibilityManagerService not registered for removed packages.

The pakcage monitor in the AccessibilityManagerService was not
watching for packages that are removed. This is needes since
1) we need to remove the package from the enabled accessibility
serivces and clean up after the removed serivice; 2) we need to
disable accessibility if the last access serivices went away.

Change-Id: I06d33b411ce60703e5a2843107323ffc87046c16
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
37fedf8b78dea969b97188fd3079fea5e71704be 14-Sep-2011 Svetoslav Ganov <svetoslavganov@google.com> Disable accessibility if all accessibility serivces are disbaled.

Accessibility was kept enabled even if all accessibility services
are disabled (explicitly by the user or removed) which was causing
the system to fire accessibility events that will never be consumed.

Change-Id: Ifb03e786ac0106687252bd1979725ffd724ad1c5
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
8bd69610aafc6995126965d1d23b771fe02a9084 23-Aug-2011 Svetoslav Ganov <svetoslavganov@google.com> Intra-process view hierarchy interrogation does not work.

The content retrieval APIs are synchronous from a client's
perspective but internally they are asynchronous. The client thread
calls into the system requesting an action and providing a callback
to receive the result after which it waits up to a timeout for that
result. The system enforces security and then delegates the request
to a given view hierarchy where a message is posted (from a binder
thread) describing what to be performed by the main UI thread the
result of which it delivered via the mentioned callback. However,
the blocked client thread and the main UI thread of the target view
hierarchy can be the same one, for example an accessibility service
and an activity run in the same process, thus they are executed on the
same main thread. In such a case the retrieval will fail since the UI
thread that has to process the message describing the work to be done
is blocked waiting for a result is has to compute! To avoid this scenario
when making a call the client also passes its process and thread ids so
the accessed view hierarchy can detect if the client making the request
is running in its main UI thread. In such a case the view hierarchy,
specifically the binder thread performing the IPC to it, does not post a
message to be run on the UI thread but passes it to the singleton
interaction client through which all interactions occur and the latter is
responsible to execute the message before starting to wait for the
asynchronous result delivered via the callback. In this case the expected
result is already received so no waiting is performed.

bug:5138933

Change-Id: I382e2d8689f5189110226613c2387f553df98bd3
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
a31f5e63743f3fc788acbd85474ec80eaf5c8b4d 28-Jul-2011 Svetoslav Ganov <svetoslavganov@google.com> InputFilter not updated on global accessibility change.

Change-Id: I35fd5fa078840abf62a3d5eac66b2eae1a79d01d
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
4e2a762eae1f6981d32e6098a95498865ad7f795 27-Jul-2011 Svetoslav Ganov <svetoslavganov@google.com> Not user generated accessibility events can change the interrogation allowing window.

1. Events not generated by the user can change the interrogation allowing window
unpredicatably. For example when a ListView lays out its children it fires an
accessibility events and changes the currently active window while the user
interaction may be happening in another window say a dialog. Now the interrogation
allowing window is changed when a new window is shown or the user has touch
explored it.

bug:5074116

Change-Id: I8dde12bbec807d32445a781eedced9b95312b3e2
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
00aabf7d187bc05408199bd687a538b2e68bdc17 21-Jul-2011 Svetoslav Ganov <svetoslavganov@google.com> Touch exploration state set to clients asynchronously and depended on talking service being enabled.

1. Upon registration of an accessibility client the latter received only
the accessiiblity state and waiting for the touch exploration state
to be sent by the system in async manner. This led the very first
check of touch exploration state is checked a wrong value to be reported.
Now a state of the accessibility layer is returned to the client
upon registration.

2. Removing the dependency on talking accessibility service to be enabled
for getting into touch exploration mode. What if the user wants to use
an accessibility service that shows a dialog with the text of the touched
view?

bug:5051546

Change-Id: Ib377babb3f560929ee73bd3d8b0d277341ba23f7
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
35bfedeaba724aeadc6f6c890269cb6bf7ef42f5 15-Jul-2011 Svetoslav Ganov <svetoslavganov@google.com> Touch exploration separate setting and API to poll the latter state.

1. Seperated touch exploration to be a seperate setting rather being
magically enabled by the system of accessiiblity is on the there
is at leas one accessibility service that speaks enabled. Now
there is a setting for requesting touch exploration but still the
system will enabled it only if that makes sense i.e. accessibility
is on and one accessibility service that speaks is enabled.

2. Added public API for checking of touch exploration is enabled.

3. Added description attribute in accessibility service declaration
which will be shown to the user before enabling the service.

4. Added API for quick cloning of AccessibilityNodeInfo.

5. Added clone functionality to SparseArray, SparseIntArray, and
SparseBooleanArray.

bug:5034010
bug:5033928

Change-Id: Ia442edbe55c20309244061cd9d24e0545c01b54f
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
4a49d9fe52a76c7f91f81113e0a8e9f97ac3f24c 17-Jul-2011 Svetoslav Ganov <svetoslavganov@google.com> Throw an exception if accessibility service has not requested to retrieve window content.

1. If an accessibility service does not request access to the window
content and does so, an exception is thrown to point the developer
to the reason.

bug:5038284

Change-Id: Ibf08f4d2c8ad8939c4f4c2e288048a4f8ff1e31b
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
63c04eeb00dd71380d5ebba701014793d8f9a2ea 14-Jul-2011 Svetoslav Ganov <svetoslavganov@google.com> Touch exploration gesture events change the window id.

1. Touch exploration start and end events are generated
by the sytstem to provide additional information for
accessibility services. Since such events do not come
from any particular window they whould not change the
id of the window that currently allows exploring its
content.

2. Touch exploration start and end events were lealing the
touch explorer class wich is private.

bug:5026258

Change-Id: Icaf3e2bd9566716f2afb876cf8e0d50813b0c76e
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
e8f95352cf4fd2bb38fd124bf5fcefddddeb0692 07-Jul-2011 Svetoslav Ganov <svetoslavganov@google.com> Addressing comments during security review of the interrogation feature.

1. Pretty much minor fixes for improving readability.

Change-Id: I76efdcc574af9a277b54eeb9fb5caf34948fcfde
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
b96a41136a9afd8e719c19488094f641f9673362 28-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Fatal system crash due to NullPointerException

1. Due to thread interleaving it was possible that
two messages are sent for requesting dispatch of
the same accessibility event and since the first
one sends the event and removes it from the pending
list the second message pulls null during the event
lookup. Look at the patch's comments for a detailed
scenario and rationale of the fix.

bug:4886129

Change-Id: If8b272ceaec7709c659ae502c3a730e63c939172
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
a0156177cdc809795dd8bc5a19943dd2b6f82b66 27-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Added scroll and text selection change accessibility events.

1. Added scrolling accessibility event to provicde feedback
when a view is scrolled.

Note: We need scroll events for ICS since even though we have
touch exploration the user does not know when something
is scrollable and not feedback is provided while scrolling.

bug:4902097

2. Added a text selection change event to provide feedback
for selection changes including cursor movement.

Note: We need the text selection change events for ICS since
even though the IME supports navigation in text fields
the user receives no feedback for the current selection/
cursor position.

bug:4586186

3. Added a scrollable property to both AccessibilityEvent and
AccessibilityNodeInfo. The info has to describe the source
in terms of all properties that make sense for accessibility
purposes and the event has this property (kinda duplicated)
since clients will aways want to know if the source is
scrollable to provided clue to the user and we want to avoid
pulling the info of the source for every accessibility event.

Change-Id: I232d6825da78e6a12d52125f51320217e6fadb11
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
1ecc1e098a531f57707218b0b38a73f6fa2759d8 22-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Minor tweak I forgot in the presious change.

Change-Id: I17854e3c824bea5b6c0ffeea45f986f0b5297054
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
7961be75f4161769f620e44dec3f5911e50ebe03 21-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> AccessibilityNodeInfo bounds inconsistent with compatibility mode.

1. In compatibility mode a window wide scaling is applied to stretch
the content. However, AccessibilityNodeInfos retrieved from that
window contain bounds in application's view of the world and need
to be scaled to properly relect what a sighted user sees.

Change-Id: Iebbb99526fc327f45b5cede89ba8c32e6ebd8845
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
9dc98e3d1764dbcf7828599b70e7a71a3c82a407 17-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Accessiiblity in right state upon connection of a test agent.

1. Enabling accessibility and disabling all enabled
accessibility service when a test client connects
the the AccessibilityManagerService.

Change-Id: I2f40cccaa0035ac1454d8c5ac84678c1542a0229
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
eeee4d2c01d3c4ed99e4891dbc75c7de69a803fa 11-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Final polish of the interrogation feature.

1. Added a new event type for notifying client accessibilitiy
services for changes in the layout. The event is fired at
most once for a given time frame and is delivered to clients
only if it originates from the window that can be interrogated.

2. Exposed the findByText functionality in AccessibilityNodeInfo.
This is very useful for an accessibility service since it allows
searching for something the user knows is on the screen thus
avoiding touch exploring the content. Touch exploring is
excellent for learning the apps but knowing them search is
much faster.

3. Fixed a bug causing an accessibiliby service not to receive
the event source in case of more than one service is registered
and one of them does not have paermission to interrogate the window.
The same event was dispatched to multiple services but if one
of them does not have interrogation permission the event is
modified to remove the source causing subsequent serivices not
to get the later.

4. Moved the getSource setSource methods to AccessibilityRecord
instead in AccessibilityEvent.

5. Hiden some protected members in AccessibilityRecod which should
not be made public since getters exist.

6. Added the View absolute coordinates in the screen to AccessibilityNodeInfo.
This is needed for fast computation of relative positions of
views from accessibility - common use case for the later.

7. Fixed a couple of marshalling bugs.

8. Added a test for the object contract of AccessibilityNodeInfo.

Change-Id: Id9dc50c33aff441e4c93d25ea316c9bbc4bd7a35
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
8643aa0179e598e78d938c59035389054535a229 20-Apr-2011 Svetoslav Ganov <svetoslavganov@google.com> Interrogation of the view hierarchy from an AccessibilityService.

1. Views are represented as AccessibilityNodeInfos to AccessibilityServices.

2. An accessibility service receives AccessibilityEvents and can ask
for its source and gets an AccessibilityNodeInfo which can be used
to get its parent and children infos and so on.

3. AccessibilityNodeInfo contains some attributes and actions that
can be performed on the source.

4. AccessibilityService can request the system to preform an action
on the source of an AccessibilityNodeInfo.

5. ViewAncestor provides an interaction connection to the
AccessibiltyManagerService and an accessibility service uses
its connection to the latter to interact with screen content.

6. AccessibilityService can interact ONLY with the focused window
and all calls are routed through the AccessibilityManagerService
which imposes security.

7. Hidden APIs on AccessibilityService can find AccessibilityNodeInfos
based on some criteria. These API go through the AccessibilityManagerServcie
for security check.

8. Some actions are hidden and are exposes only to eng builds for UI testing.

Change-Id: Ie34fa4219f350eb3f4f6f9f45b24f709bd98783c
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
c321c19fc91bfec9a74039ed4d37b815dd4ef379 04-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Fixing a bug I introduced during my last merge.

Change-Id: I6474ca94a6ef9bd17a5670a4baa51673f3c2f5d0
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
f9886f3ee9db23cc5a553b92e2aeff0ae842c915 11-May-2011 Svetoslav Ganov <svetoslavganov@google.com> AccessiblityManagerService not cleaning up dead binders.

1. AccessibilityManagerService was keeping handles to dead
IAccessibilitymanagerClients - now doing so.

2. AccessibilityManagerService was lazily cleaning up dead
IAccessibilityServiceConnections - now using a callback.

3. Cleaned up the book keeping of enabled services.

4. Fixed a bug that the input filter is still enabled
when disabling accessibility.

Change-Id: I5e9af7ab684a3b71e8ee51125b1262a17e960eb0
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
cc4053e031371456fe54d51bbad1db721db4ae38 23-May-2011 Svetoslav Ganov <svetoslavganov@google.com> Accessibility serviceconfiguration via meta-data

Note: This is a part of two CL change and contains the
system changes without updates to the settings.

1. Added a mechanism for configuring an accessibility service via
XML file specified in a meta-data tag (similar to IMEs).

2. Added property for specifying a settings activity for an
accessibility service.

3. Refactored the APIs in AccessibilityManager to return
lists of AccessiblityServiceInfo instead ServiceInfo
since the former describes an AccessibilityService in
particular (similar to IMEs).

Change-Id: Ie8781bb7e0cdb329e583b6702a612a507367ad7b
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
a3e261d506551713477adb2fd47d1a65b94e64d8 27-Apr-2011 Svetoslav Ganov <svetoslavganov@google.com> The accessibility input filter state was not unregistered when
no spoken feedback accessibility services are regitstered.

bug:4343996

Change-Id: Ie709ac24baa084cf3627d6adb6caf1550c399f8b
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
736c2756bf3c14ae9fef7255c119057f7a2be1ed 23-Apr-2011 Svetoslav Ganov <svetoslavganov@google.com> Touch exploration feature, event bubling, refactor

1. Added an Input Filter that interprets the touch screen motion
events to perfrom accessibility exploration. One finger explores.
Tapping within a given time and distance slop on the last exlopred
location does click and long press, respectively. Two fingers close
and in the same diretion drag. Multiple finglers or two fingers in
different directions or two fingers too far away are delegated to
the view hierarchy. Non moving fingers "accidentally grabbed the
device for the scrren" are ignored.

2. Added accessibility events for hover enter, hover exit, touch
exoloration gesture start, and end. Accessibility hover events
are fired by the hover pipeline. An accessibility event is
dispatched up the view tree and the topmost view fires it.
Thus predecessors can augment the fired event. An accessibility
event has several records and a predecessor can optionally
modify, delete, and add such to the event.

3. Added onPopulateAccessibilityEvent and refactored the existing
accessibility code to use it.

4. Added API for querying the currently enabled accessibility services
by feedback type.

Change-Id: Iea2258c07ffae9491071825d966dc453b07e5134
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
3fb3d7c4e756bd32d5abde0abca9ab52d559bc84 23-Apr-2011 Adam Powell <adamp@google.com> Revert "Touch exploration feature, event bubling, refactor"

This reverts commit ac84d3ba81f08036308b17e1ab919e43987a3df5.

There seems to be a problem with this API change. Reverting for now to
fix the build.

Change-Id: Ifa7426b080651b59afbcec2d3ede09a3ec49644c
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
ac84d3ba81f08036308b17e1ab919e43987a3df5 05-Apr-2011 Svetoslav Ganov <svetoslavganov@google.com> Touch exploration feature, event bubling, refactor

1. Added an Input Filter that interprets the touch screen motion
events to perfrom accessibility exploration. One finger explores.
Tapping within a given time and distance slop on the last exlopred
location does click and long press, respectively. Two fingers close
and in the same diretion drag. Multiple finglers or two fingers in
different directions or two fingers too far away are delegated to
the view hierarchy. Non moving fingers "accidentally grabbed the
device for the scrren" are ignored.

2. Added accessibility events for hover enter, hover exit, touch
exoloration gesture start, and end. Accessibility hover events
are fired by the hover pipeline. An accessibility event is
dispatched up the view tree and the topmost view fires it.
Thus predecessors can augment the fired event. An accessibility
event has several records and a predecessor can optionally
modify, delete, and add such to the event.

3. Added onPopulateAccessibilityEvent and refactored the existing
accessibility code to use it.

4. Added API for querying the currently enabled accessibility services
by feedback type.

Change-Id: Iec03c6c3fe298de3f14cb6efdbb9b198cd531a0c
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
43a17654cf4bfe7f1ec22bd8b7b32daccdf27c09 07-Apr-2011 Joe Onorato <joeo@google.com> Remove the deprecated things from Config.java. These haven't been working since before 1.0.

Change-Id: Ic2e8fa68797ea9d486f4117f3d82c98233cdab1e
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
0029c66203ab9ded4342976bf7a17bb63af8c44a 30-Mar-2011 Jeff Brown <jeffbrown@google.com> Add input filter mechanism for accessibility.

This patch adds a mechanism for capturing, filtering, transforming
and injecting input events at a very low level before the input
dispatcher attempts to deliver them to applications. At this time,
the mechanism is only intended to be used by the accessibility
system to implement built-in system-level accessibility affordances.

The accessibility input filter is currently just a stub.
It logs the input events receives and reinjects them unchanged,
except that it transforms KEYCODE_Q into KEYCODE_Z.

Currently, the accessibility input filter is installed whenever
accessibility is enabled. We'll probably want to change that
so it only enables the input filter when a screen reader is
installed and we want touch exploration.

Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java
6e6cd7a5660af1a4b5a9ad091c41ef1c72ad2000 30-Mar-2011 Jeff Brown <jeffbrown@google.com> Move accessibility manager service to own package.

Change-Id: I0d73737a21615f0ff0abc80b757fb8c9bcb50be5
/frameworks/base/services/java/com/android/server/accessibility/AccessibilityManagerService.java