History log of /frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
e20a177d3f147f3011647c3bdab401f90b2c5d1d 26-Sep-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding a global accessibility action to open quick settings.

1. Added APIs for opening the quick settings to the StatusBarManagerService
and the local StatausBarManager. The new APIs are protected by the old
EXPAND_STATUS_BAR permission.
Renamed the expand* and collapse* non-public APIs that are expanding
the notifications to expandNotifications* collapseNotifications* to
better convey what they do given that this change adds
expandQuickSettings* and collapseQuickSettings*.
Added a global action to the accessibility layer to expand the quick
settings which is calling into the new status bar manager APIs.

bug:7030487

Change-Id: Ic7b46e1a132f1c0d71355f18e7c5a9a2424171c3
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
53b0fda5fd7c532fc1d93abd5f8a85276821cc6d 06-Aug-2012 Scott Main <smain@google.com> misc doc bugs.
Fix sdk samples path
Fix method signature in fragment doc code snippet
Fix typo in a11y javadoc code snippet
Fix markup error in brands page
Fix markup error on content providers doc
Fix typo on about>start page

Change-Id: Ie2a528dd4fbd19e5cb1c0844f6fc6272669c8ab9
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
636fd528f7ad51f565a390226d9f469f8c675ccf 06-Jun-2012 Dianne Hackborn <hackbod@google.com> Docs (mostly): enumerate JELLY_BEAN target SDK changes.

Okay this isn't entirely docs. I have un-hidden the new permission
for binding to accessibility services; we were going to go out with
it hidden since it didn't go into factory ROM, but now that we are
doing other things we might as well expose it.

Also changed a log from E to W, since it is not an error.

Change-Id: I9226c95e3b63e12218fe41dc3f4290d9824a9e5c
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
1e7456ba74f93cdf80dc430aa082cc3c271b30b1 17-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Fixing the build for real.

Change-Id: I792d029c7fff4d96fbe238ff4b3f268cb8603b95
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.java
87bd0dccf7f2558ea1a5e0fce523aea022709834 08-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Renaming the constants for activation and long press.

1. We will have a double tap to activate an item and
tap and hold to perform a long press.

Change-Id: Ibd9d8774e5a4693d8868d1128e55a82ff0c3a80b
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
65d98ad5b3f2e5ec03f14cb0538c572a427ae1a8 03-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Remove accessibility gestures for clockwise and counter clock wise circle.

1. The clockwise and counter clockwise circle gestures are difficult to
perform for a blind user. Some user studies have shown that so nuke them.

bug:6435260

Change-Id: I81d23bd3c450239fe17b4b8c60bafab00daa480a
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.java
0846e29d0b5640cfad4496c8484fb9aaa2ba4ccf 19-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding API for getting the root node info in the active window.

1. This APIs is useful for accessibility services since very often
they want to get access to the root node in the current window
to determine where accessibility focus is and subsequently find
a next view to take accessibility focus.

Change-Id: Ide5231f832d9ce2e9b14dc411dfd675f753a4edb
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.java
110414928ae13674b7ec6b816a45cf70ed521683 03-Apr-2012 Joe Fernandez <joefernandez@google.com> am c1a0e54d: am b459b619: am 945b7cb3: Merge "docs: Accessibility Dev Guide (subsumes Accessibility Best Practices)" into ics-mr1

* commit 'c1a0e54de12aee41163b84a25ea8dfc8b64304dc':
docs: Accessibility Dev Guide (subsumes Accessibility Best Practices)
e1302edd40c5cc264f842e17e3796e0a11d6f045 06-Feb-2012 Joe Fernandez <joefernandez@google.com> docs: Accessibility Dev Guide (subsumes Accessibility Best Practices)

Change-Id: Id7e3f647042d2afd390abe851be1c3b561af33ca
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
f76a50ce8fdc6aea22cabc77b2977a1a15a79630 09-Mar-2012 Ken Wakasa <kwakasa@google.com> Fix obvious typos under frameworks/base/core

Change-Id: Ia5fc3db1bb51824e7523885553be926bcc42d736
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.java
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/core/java/android/accessibilityservice/AccessibilityService.java
b303d8381d734f48c4e1de4f11bf25950b28adf1 13-Oct-2011 Scott Main <smain@google.com> docs: a couple notes for a11y methods in View and cleanup to the
A11y service HTML to be semantically correct and thus improve its accessibility :)

Change-Id: I483a8a441d802b056f68f82e0e782d86a73298ac
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.java
38e8b4e5bc3c93affdffbc064fd9db5aeccc3e8e 30-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Updating accessibility documentation.

Change-Id: Ice8cf9ac6918b3bfa553776c68d4619fa6559cf8
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.java
7ed6ee5692c808cf0ebb3ee208fc8ee1314622c2 11-Sep-2009 Dianne Hackborn <hackbod@google.com> Fix issue #1983406: Soft keyboard doesn't show up in an EditText with "digits" attribute set

Also pretend to fix #2054990 (com.android.frameworktest: java.lang.NullPointerException
at android.accessibilityservice.AccessibilityService$IEventListenerWrapper.executeMessage(
AccessibilityService.java:215))... simply by making the variable that apparently was
null final, to assure myself that there is no possible way in the world for it to be
null. :p

Change-Id: I73e337d65b8360721896a0296691257b3e47564b
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
85f6fb713feb258197f17a86c45874d542194b71 28-Aug-2009 Charles Chen <clchen@google.com> Fixing bug 2086021. AccessiblityService could sometimes get a null pointer
exception if multiple accessibility services are running and there are
several events all happening within a short period of time.
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
7f2054392e9957d3ba8579ef08c29cfb27df564e 28-Jul-2009 Dianne Hackborn <hackbod@google.com> Updates from API review.

* AccessibilityService -- document onBind() to not be implemented.
* GestureLibrary.getLearner() -- needs to be hidden.
* IntentSender -- remove protected constructors, document that it is retrieved from a PendingIntent.
* Hide permissions: SHUTDOWN, STOP_APP_SWITCHES.
* Context -- hide BACKUP_SERVICE.
* ContextWrapper -- hide getSharedPrefs bla h blah
* Intent.parseUri() -- fix docs.
* ApplicationInfo.FLAG_TEST_ONLY?!?
* Hide MockContext.getSharedPrefs blah blah
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
75986cf9bc57ef11ad70f36fb77fbbf5d63af6ec 15-May-2009 svetoslavganov <svetoslavganov@google.com> Accessibility feature - framework changes (replacing 698, 699, 700, 701 and merging with the latest Donut)
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java