History log of /frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
6d17a936f73976971135aa1e6248662533343292 28-Apr-2012 Svetoslav Ganov <svetoslavganov@google.com> Text traversal at various granularities.

1. Implementing text content navigation at various granularities.
For views that have content description but no text the
content description is the traversed at character and word
granularities. For views that inherit from TextView the
supported granularities are character, word, line, and page.

bug:5932640

Conflicts:

core/java/android/view/View.java

Conflicts:

core/java/android/view/View.java

Change-Id: I66d1e16ce9ac5d6b49f036b17c087b2a7075e4c0
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/core/java/android/view/accessibility/AccessibilityEvent.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/core/java/android/view/accessibility/AccessibilityEvent.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/view/accessibility/AccessibilityEvent.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/view/accessibility/AccessibilityEvent.java
51ab90cab1609cf0ddd2dfe5a660f020d823d4d5 09-Mar-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding an announcement type accessibility event and a method on View to announce.

1. The need for sending an accessibility event to announce a context change
which does not cleanly fit into the existing UI transition UI events has
come quite a few time in application development. To avoid retrofitting
accessibility event types that do not semantically match the intent to
just announce a short message this patch is adding specialized event type.
Also a helper method on View is added to sheild developers from knowing
how to construct and send such an event.

bug:5977979

Change-Id: Iaf5f620426f8616be67fbf243a02ad5b606c949b
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/core/java/android/view/accessibility/AccessibilityEvent.java
e9dc7c9f031b494c6ebe156de957f0a8f2cd58b0 19-Nov-2011 Svetoslav Ganov <svetoslavganov@google.com> am bdc2912d: am d8a3cabc: Merge "Text selection AccessibilityEvents are missing text." into ics-mr1

* commit 'bdc2912da64e5e6402c73997d637224d905ae825':
Text selection AccessibilityEvents are missing text.
84dd52e394d27b5cdf638132808e2585a9049480 18-Nov-2011 Svetoslav Ganov <svetoslavganov@google.com> Text selection AccessibilityEvents are missing text.

The text selection change event was not added to the text
populating accessibility events in View.

bug:5638709

Change-Id: Ie7e319bc07d7e6c48f178a6c1bd22b1fe32ff515
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/core/java/android/view/accessibility/AccessibilityEvent.java
9920f4fdeaa3a4c597f62c3d082becc48ea8a7ab 08-Oct-2011 Svetoslav Ganov <svetoslavganov@google.com> Accessibility text changed event text not populated.

Added the TYPE_VIEW_TEXT_CHANGED event to the populating events.

bug:5430831

Change-Id: I78e87640ea4279227d89f399ad43e9b88eb4a486
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
d9ee72fddb8be40e414a831fb80458dc48699613 06-Oct-2011 Svetoslav Ganov <svetoslavganov@google.com> Fixing errors in position information of scrollable views reported for accessibility.

1. ScrollView/HorizontalScroll view were reporting only the scroll X and Y but
failed to convey the max scroll along X and Y so the position can be determined.

2. WebView was not reporting correctly its scroll position for accessibility.

3. Some descendants of AdapterView were reporting incorrect position information.

4. Updated the accessibility docs with some details about the scroll information.

5. Cleaned up duplicated code.

bug:5412132
bug:5412265

Change-Id: I165e73ecde027dad811425b9f395a3f758c923ba
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
82e236d72ac197d6673d0b4d484fe5f0b9436731 30-Sep-2011 Svetoslav Ganov <svetoslavganov@google.com> The logic for not populating text to some accessibility events is scattered.

1. Some accessibility evenents should not and were not dispatched for
text population but there was no centralized location for enforcing
this - rather the system was firing them in a specific way or there
were conditions in a few places enforcing that. Now this is centralized
and clean.

2. Updated the documentation with some new event types the were lacking.

3. Explicitly stated in the documentaition which events are dispatched to
the sub-tree of the source for text populatation.

bug:5394527

Change-Id: I86e383807d777019ac98b970c7d9d02a2f7afac6
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
e4aa13b20166219a62916a92294055e7cc5c9f10 01-Aug-2011 Svetoslav Ganov <svetoslavganov@google.com> AccessibilityEvent#toString() always reports -1 for record count.

1. The implementation of toString() was calling a wrong method
for the record count.

bug:5087078

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

Change-Id: Ice8cf9ac6918b3bfa553776c68d4619fa6559cf8
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
a20cdc06e599c6fef784a0a479e8329f95e4bd09 27-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Fixing the build

Change-Id: Ic3664e5cd812d5fe59c9cf2657a441ca76a61135
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/core/java/android/view/accessibility/AccessibilityEvent.java
34e350daf89aed09ac748c2185f4506772a63b3f 21-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> ListView do not fire accessibility hover events.

1. AccessibilityEvent was incorrectly setting the
connection of an owned AccessibilityRecord after
the record is initialized since during initialization
the record may become sealed.

bug:4724101

Change-Id: I39087dc8023c62252f31431ece23de901dc45972
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/view/accessibility/AccessibilityEvent.java
9210ccbdc3629cead65a822d729e1783a773118c 09-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> AccessibilityNodeInfo and AccessibilityEvent to initialized properly.

Change-Id: Id3a1b33a222790214820af4a8b49378f08e53558
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/view/accessibility/AccessibilityEvent.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/view/accessibility/AccessibilityEvent.java
887e1a17eb9b12448f5929791b564565b2665aab 30-Apr-2011 Svetoslav Ganov <svetoslavganov@google.com> Touch exploration - nits

Change-Id: Ie49558e0a81218dbad70c02f81dd7a59b3213d5c
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/core/java/android/view/accessibility/AccessibilityEvent.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/core/java/android/view/accessibility/AccessibilityEvent.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/core/java/android/view/accessibility/AccessibilityEvent.java
c0a8cd10a5829bf4e94ee073ba6f553128e9d8e9 19-Mar-2011 Svetoslav Ganov <svetoslavganov@google.com> Text in accessibility events not consistent

bug:2513822

Text added to accessibility events is truncated to max
length. However, the fromIndex and toIndex properties
are relative to the text before being truncated, thus
potentially our of bound. Removed the max length
limitation because test very rarely is longer that
500 characters and in the cases in which text is longer
than 500 character it will not be a real problem to
pass a bit more data through an IPC (very rarely).

Change-Id: Ie70ac630dfeb56d4f59079abb2f46d07582796b6
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
9efd078c6bf513e8c6bf59ce57e6f9c038fdf3ee 14-Apr-2010 Svetoslav Ganov <svetoslavganov@google.com> 2593810 Accessibility event's parcelableData property not nullified during recycling

Change-Id: I88d6f3d63d7ff0fbdd88fb9cb642349029838b31
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/view/accessibility/AccessibilityEvent.java