History log of /frameworks/base/core/java/android/view/accessibility/AccessibilityRecord.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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/AccessibilityRecord.java
8b6c7dd2fe1016a8f765f98e8114d5f491f02353 11-Oct-2011 Svetoslav Ganov <svetoslavganov@google.com> Add AccessibilityRecord#getMaxScrollX and #getMaxScrollY to the pubic API

The methods were hidden for the previoud release since they were added
too close to the SDK final date.

bug:5424373

Change-Id: I812b9809223db75636b04549500f023820b6eb5a
/frameworks/base/core/java/android/view/accessibility/AccessibilityRecord.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/AccessibilityRecord.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/core/java/android/view/accessibility/AccessibilityRecord.java
47b779b9f9c2e7948ae8d45ea07a10f1ad07d135 17-Jul-2011 Svetoslav Ganov <svetoslavganov@google.com> Scroll events should indicate whether or not they have pixel data.

1. Updated all integet properties of AccessibilityRecord to be set to -1
so this is a clue to the client that this property is irrelevant for
the current event type.

bug:5031598

Change-Id: Ifedc15bf2249847cbc6cbcb83f5732e17b8b2903
/frameworks/base/core/java/android/view/accessibility/AccessibilityRecord.java
38e8b4e5bc3c93affdffbc064fd9db5aeccc3e8e 30-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Updating accessibility documentation.

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

Change-Id: Ic3664e5cd812d5fe59c9cf2657a441ca76a61135
/frameworks/base/core/java/android/view/accessibility/AccessibilityRecord.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/AccessibilityRecord.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/AccessibilityRecord.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/AccessibilityRecord.java
d36a699410d8b65deede229df8414dde04c3421c 19-May-2011 Svetoslav Ganov <svetoslavganov@google.com> Fixing my build fix

Change-Id: I8393e0172367de730123b2fa9d743b1ecb2eb087
/frameworks/base/core/java/android/view/accessibility/AccessibilityRecord.java
887e1a17eb9b12448f5929791b564565b2665aab 30-Apr-2011 Svetoslav Ganov <svetoslavganov@google.com> Touch exploration - nits

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