History log of /frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
24142819b8e6181091b2b18e71fc019a649b2726 14-Apr-2016 Steven Dao <sdao@google.com> Populate RangeInfo correctly when acquiring from pool

Bug: 27136599
Change-Id: I836b2ae3bf9b2ed5fc4afeb744e2cf3a500cc4a4
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
72fde85f7fb227f48f7c0a6e69d9ac174a8e3abc 05-Apr-2016 Phil Weaver <pweaver@google.com> Remove unusable a11y APIs for ClickableSpans.

This change essentially backs out ag/683646, which added an API to click
on ClickableSpans within a TextView. This API has the flaw, however,
that ClickableSpans are not parcelable, so they are not in general
reported to AccessibilityServices. That means that services will have no
idea what they are activating.

Since the API is not usable end-to-end, I'm backing it out before the
API is final.

Bug: 17726921
Change-Id: I541c6218f2899ff67a6b32a13fd9ae6f3b53b3c4
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
297017d1548530a0444637b02e01371ba3acf7b6 30-Mar-2016 Jeff Sharkey <jsharkey@android.com> AccessibilityNodeInfo shouldn't touch extras.

The extras may contain custom Parcelables which aren't in the
system's default classpath, so touching them would end up clobbering
the contents.

Update code to leave the parcelled data untouched inside the bundle
until someone tries reading the extras.

Bug: 27897919
Change-Id: I99381dd50c9a0e8887667076362ea98805f0437c
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
cbfd71c66d66b8a8bbb8a6e4224f66728bb42ffa 02-Feb-2016 Casey Burkhardt <caseyburkhardt@google.com> Merge "Exposes accessibility importance on AccessibilityNodeInfo"
2d80ae4fbbafa9396148b0f45172f73514d0e98b 31-Jan-2016 Casey Burkhardt <caseyburkhardt@google.com> Exposes accessibility importance on AccessibilityNodeInfo

This allows a service configured with FLAG_INCLUDE_NOT_IMPORTANT_VIEWS
to discover which views in the hierarchy were evaluated as important.

Change-Id: Ife9411e41326b4872fc0682773722b9dae7ce994
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
7ef48bec6f92cef0f4ed00e79b0a36d39f55596e 31-Jan-2016 Casey Burkhardt <caseyburkhardt@google.com> Update AccessibilityAction docs

Adds info to AccessibilityAction on how the class is typically used.
Also adds a warning to indicate a view must be important for accessibility
in order for the actions on a View to be discovered.

Change-Id: I5a48712e61a2411f331321142df4e5695e002de5
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
40ded287c432637158954f84a6d9cdacffc8f181 26-Jan-2016 Phil Weaver <pweaver@google.com> Clean up some accessibility documentation.

Removed and updated some obsolete documentation about window
content. Stated the purpose of accessibility. Updated docs
for getTextSelection to include its ability to get cursor
position. Clarified wording for accessibility overlays.

Change-Id: Iaa11b499c2b7ece12ca182d336376d97b961b54f
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
1f2225486d649adce81c66a0ce696bf2d84a256d 08-Jan-2016 Phil Weaver <pweaver@google.com> Pass drawing order information to accessibility.

Bug: 22721935
Change-Id: I45a2be7c174c8b5a469b68a45dec0eb536825d92
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
103a577c936f611d2dd22ef718635a4f8d6c4cd4 13-Oct-2015 Steven Dao <sdao@google.com> Add missing actions to getActionSymbolicName
- This improves the output of AccessibilityAction.toString()
for debugging purposes.

Change-Id: I99274005d826d3e256f7ee3dbaa3315677f2067f
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
af87c70547df628a15746a47669835ec5e2c65c8 23-Jun-2015 Maxim Bogatov <maximbogatov@google.com> am d6bdd65a: am 9d919a23: am e5a4a91c: Merge "Transfer a11y node with a11y event" into mnc-dev

* commit 'd6bdd65aa47457740cbaeba162c864e48c14f83d':
Transfer a11y node with a11y event
2f55a3f0b887ec8966d4cf1858b72612fcf358c2 10-Jun-2015 Maxim Bogatov <maximbogatov@google.com> Transfer a11y node with a11y event

b/19870218

Change-Id: I29519d029cb7a154de09627afab7a0307abe85bd
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
3b3fd00bf165f94ba5d94d01462609a12fa857e3 08-Jun-2015 Mady Mellor <madym@google.com> resolved conflicts for merge of 1612c73a to master

Change-Id: Iffbd707f14fa42c12c35e18ff6826cebd00c7bf8
e860891b1a7d4c1b581f294fa5831999caac6506 05-Jun-2015 Mady Mellor <madym@google.com> Change stylus button press to context click in View - API review feedback

Updates all references in View's onStylusButtonPress to onContextClick
as per API review feedback.

Additionally listens for mouse right clicks and calls the onContextClick
method for these as well for the stylus button press.

Bug: 21572278
Change-Id: I5c1ee8c8f23a77d7c677b86356e89d0e4fc40056
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
b5c87cb27e76d8c62584d6302816600bd03d55ef 01-Jun-2015 Alan Viverette <alanv@google.com> am b88314ad: am 508b6d2d: am 242b9c4e: Merge "Fix row/column order when unparcelling CollectionItemInfo" into mnc-dev

* commit 'b88314ad72669c2b91f2e5c6edf73f8ed02f0024':
Fix row/column order when unparcelling CollectionItemInfo
faeac960cc4faa9ced011f67feb1327aafda44bf 01-Jun-2015 Alan Viverette <alanv@google.com> Fix row/column order when unparcelling CollectionItemInfo

Bug: 21527853
Change-Id: I02a75b9395a4d573f5fd49abcbd282b35e2c8f3c
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
eaf87a3f68bf5b7a133bf5fd8236bbf7c763e6f5 15-May-2015 Alan Viverette <alanv@google.com> am 05e58407: am 72fd6186: am 2a576d9e: Merge "Invalidate old accessibility bounds on CONTENT_CHANGE" into mnc-dev

* commit '05e58407650c6a2d9dfc3130f15c38104baa823d':
Invalidate old accessibility bounds on CONTENT_CHANGE
a7ea65e239581c84c3ae80f42f5a1827d48fc876 15-May-2015 Alan Viverette <alanv@google.com> Invalidate old accessibility bounds on CONTENT_CHANGE

Bug: 20950124
Change-Id: Id19924358b538f9b7754de3a0c019433817dc1fc
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
04694d60a57a05ae7d87f9e1ba7bffba99d2cc44 14-May-2015 Alan Viverette <alanv@google.com> am 9f233c51: am 462e926f: am f93d16bc: Merge "Avoid sealed check when unparceling AccessibilityNodeInfo" into mnc-dev

* commit '9f233c51b2e08fc96d327f83a06c6c36a804ae8f':
Avoid sealed check when unparceling AccessibilityNodeInfo
c921f27694b1f4e15399f77c97a5992aebd70726 14-May-2015 Alan Viverette <alanv@google.com> Avoid sealed check when unparceling AccessibilityNodeInfo

Previously the unparceling code relied on addAction(), which would
incorrectly crash if the node was sealed.

Bug: 21135077
Change-Id: I773ac27b2dee501ffea0a0587536a192af402c32
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
bbac0f7c73210cb076d51853c5fd91d5847b0b41 08-May-2015 Maxim Bogatov <maximbogatov@google.com> Merge "Add support of performing clicks on ClickableSpans from AccessibilityService"
32e59d59f4362b6115593ea5c5abfb940fdf04a9 01-May-2015 Maxim Bogatov <maximbogatov@google.com> Add API for set progress on ProgressBar/SeekBar

b/12912083

Change-Id: I3a7807f0ac40220139da21248d539fa796d0a544
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
219b41dd507ecdacaa78c2f7a19654282df4897e 01-May-2015 Maxim Bogatov <maximbogatov@google.com> Add support of performing clicks on ClickableSpans from AccessibilityService

Two optional parameters were added for ACTION_CLICK.
ACTION_ARGUMENT_CLICK_SPAN_INDEX_INT represents index of ClickableSpan to click on
ACTION_ARGUMENT_CLICK_CHARACTER_INDEX_INT represents index of character.
The first span that added for that character will be triggered.
If none of above parameters are passed with action the view will be clicked

b/17726921

Change-Id: Ia4d3994c1bca950319557ec7cdb2df84314d7519
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
d274400205d054010e60ddd69f1535bedf41d96b 01-May-2015 Mady Mellor <madym@google.com> resolved conflicts for merge of 04f2fe39 to master

Change-Id: I9cd9efb3ead33cef9a0de95417d71d535cbc1bce
e82067b57595a2bce656e5ba3a9bcf19048f2f25 30-Apr-2015 Mady Mellor <madym@google.com> Add onStylusButtonPress listener to View

The gesture is: stylus touching screen + button pressed, the event
is recognized when the button is pressed, not when it's released.
It can be pressed during DOWN or MOVE.

If the stylus touch + press button is occurring longpress cannot
occur and vice versa. Also adds the haptic feedback and accessibility
bits specific to the new gesture.

Bug: 19620479
Change-Id: Ibc4654978ef39e7b4251d17636453d90f3bf622d
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
ac6ffce1711b84682521e6c2e55865c60929fd88 27-Apr-2015 Maxim Bogatov <maximbogatov@google.com> Add accessibility actions for scrolling in different directions

b/20157498

ACTION_SCROLL_UP, ACTION_SCROLL_DOWN, ACTION_SCROLL_LEFT and ACTION_SCROLL_RIGHT
actionos were added in addition to ACTION_SCROLL_FORWARD/BACKWARD

Change-Id: I8d5182a8add32085a354b280496b3d38ec79be32
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
23f4432437b2ab742971055b7eb79b346894f24b 07-Apr-2015 Alan Viverette <alanv@google.com> Add accessibility action for scrolling to a collection position

Cleans up verbose R package in GridView, accessibility action docs,
and some lint warnings in AccessibilityNodeInfo. Makes the action IDs
for SHOW_ON_SCREEN and SCROLL_TO_POSITION public so that we can
guarantee they won't change (and thus reference them in support lib).

Change-Id: Ica53b7be7a68b84054b9bac1fc7958a21a42e089
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
1579edcabac0fbdc8abc938d896f3bde9b7c3758 01-Apr-2015 Alan Viverette <alanv@google.com> Fix docs

Bug: 20011464
Change-Id: Ifcda3e562a3baea474b824e5ac2adcd36e17ae60
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
26c44eeecf665702c5398803d8b1145e0050a07d 25-Mar-2015 Alan Viverette <alanv@google.com> Add accessibility action for making a node visible on screen

Bug: 19872425
Change-Id: I39c971f949d08d6573da2e5567dca1e187a17d7e
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
5738fec00db65e0ee246475a7236e57ba3ee8d55 29-Jan-2015 Svetoslav <svetoslavganov@google.com> AccessibilityNodeInfo refresh returns a stale state.

AccessibilityNodeInfo refresh was getting the latest cached
state but this is not good enough as an accessibility service
can execute an action on the node and then refresh it to get
the new state.

bug:16954787

Change-Id: I004b4987b8dc423a2ab7031a4fbfe64365ddd7fe
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
6c70290ff0b20329c8f173d5c3423eb83ddc46f1 10-Oct-2014 Svetoslav <svetoslavganov@google.com> Adding APIs to enable apps to influence accessibility traversal.

Accessibility focus is a token that can be put on any view and is
entirely controlled by accessibility services which decide whether
to put accessibility focus on a given view and what the traversal
strategy is.

Currently accessibility service use the view tree structure for
traversal which does not always reflect the logical order and the
user experience is sub-optimal. In such cases apps should be able
to influence how they are traversed for accessibility.

This change adds the notion of an accessibilty traversal order.
If a view has next in the traversal, an accessibility service has
to traverse the content of this view before traversing the content
next one.

This change will enable accessibility service to move away from
using the view tree and use spatial location of the content while
app developers can also influence the treversal order.

bug:17319923

Change-Id: Ib67ae4577f30b2c96575c71538dc1afdea08bfd3
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
029942f77d05ed3d20256403652b220c83dad6e1 12-Aug-2014 Alan Viverette <alanv@google.com> Add API for obtaining max text length for accessibility

BUG: 16736956
Change-Id: I15ffb9bf68e074adf3e0dbcd230367e115c03e3c
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
fccbff5f021a6f95fe1c18f55866545c767ef8eb 08-Jul-2014 Alan Viverette <alanv@google.com> Add API on AccessibilityNodeInfo for retrieving TextView error

BUG: 11155198
Change-Id: Ie01b92e1071ff584b360cfa3ece4320ad05e4aae
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
5c4cd189f298b3ddb9a5e8afc5f68546a9f96726 21-May-2014 Svetoslav <svetoslavganov@google.com> Fixing bugs due to the new custom accessibility action APIs.

1. AccessibiltiyAction was incorectly throwing an exception when
a custom action was constructed.

2. AccessibilityManagerService should no longer enforce only standard
actions as we allow custom ones too.

bug:15110963

Change-Id: Iea57e0a6449b87bd8d103c55ca255e80705f2565
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
8d5f3fa6455c1eedb4f31bbaf075f2c1f9a2887a 20-May-2014 Kristian Monsen <kristianm@google.com> Consider addAction(int action) to possibly be a bit mask

bug=15092606

Change-Id: I885808b3f4d2337129d1660300be8e926f8a8425
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
74bc19476536f2b5462eaa29e6f3029ee897c16d 29-Apr-2014 Kristian Monsen <kristianm@google.com> Adding custom events to AccessibilityNodeInfo

Change-Id: Id7a1985d1a6c4a9f7153f6d4d7e45f80c8d2b2b0
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
1e0d4af9986c8c2a658769a63bf8b385d25e0435 11-Apr-2014 Svetoslav <svetoslavganov@google.com> Adding system support for a single accessibility focus.

Now that we have APIs to query all interactive windows and allow
an accessibility service to put accessibility focus in each of
them we have to guarantee that there is a single accessibility
focus. This is required for correct operation of the touch
explorer as on double tap in clicks in the center of the focused
area, hence having more that one focus is an issue. Also the
system is maintaining a single input focus so now accessibility
focus behaves consistently with that.

bug:13965563

Change-Id: I0b5c26dadfabbf80dbed8dc4602073aa575ac179
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
8e3feb15c5aec2c72b0ef120a1da325e1e8f0dda 24-Feb-2014 Svetoslav <svetoslavganov@google.com> Added accessibility APIs for introspecting interactive windows.

1. The old introspection model was allowing querying only the active window
which is the one the user is touching or the focused one if no window is
touched. This was limiting as auto completion drop downs were not inspectable,
there was not way to know when the IME toggles, non-focusable windows were
not inspectable if the user taps them as until a screen-reader starts
introspecting the users finger is up, accessibility focus was limited to
only one window and the user couldn't use gestures to visit the whole UI,
and other things I can't remember right now.

The new APIs allow getting all interactive windows, i.e. ones that a
sighted user can interact with. This prevents an accessibility service
from interacting with content a sighter user cannot. The list of windows
can be obtained from an accessibility service or the host window from an
accessibility node info. Introspecting windows obey the same rules for
introspecting node, i.e. the service has to declare this capability
in its manifest.

When some windows change accessibility services receive a new type
of event. Initially the types of windows is very limited. We provide
the bounds in screen, layer, and some other properties which are
enough for a client to determined the spacial and hierarchical
relationship of the windows.

2. Update the documentation in AccessibilityService for newer event types.

3. LongArray was not removing elements properly.

4. Composite accessibility node ids were not properly constructed as they
are composed of two ints, each taking 32 bits. However, the values for
undefined were -1 so composing a 64 long from -1, -1 prevents from getting
back these values when unpacking.

5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added
a check that enforces such trees to be well formed on dev builds.

6. Removed an necessary code for piping the touch exploration state to
the policy as it should just use the AccessibilityManager from context.

7. When view's visibility changed it was not firing an event to notify
clients it disappeared/appeared. Also ViewGroup was sending accessibility
events for changes if the view is included for accessibility but this is
wrong as there may be a service that want all nodes, hence events from them.
The accessibility manager service takes care of delivering events from
not important for accessibility nodes only to services that want such.

8. Several places were asking for prefetching of sibling but not predecessor
nodes which resulted in prefetching of unconnected subtrees.

9. The local AccessibilityManager implementation was relying on the backing
service being ready when it is created but it can be fetched from a context
before that. If that happens the local manager was in a broken state forever.
Now it is more robust and starts working properly once the backing service
is up. Several places were lacking locking.

bug:13331285

Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
4cd353c038ec3c21f25c12897992e5e9826fe824 13-Feb-2014 Guang Zhu <guangzhu@google.com> add new accessibility action for EditText to set text content

Bug: 12872344
Change-Id: I85a3805ab0c34b96a7d4228f2382c8ff664e36e8
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
76769ae02e713f50816ee67ff618b748d95050a8 13-Feb-2014 Alan Viverette <alanv@google.com> Add selection properties to CollectionInfo, CollectionItemInfo

BUG: 12552541
Change-Id: Iae10abc02eeffea7c7fcb25020b343181e1e3482
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
cdd2eddcb288763341172ead488e92cafb19bab6 12-Feb-2014 Alan Viverette <alanv@google.com> Set properties for pooled CollectionItemInfo, CollectionInfo

BUG: 12978446
Change-Id: I64a366952090ab663ffef43a1d210528805e113c
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
f0aed09ed8153043e40b3ac99788d47ba0831306 07-Nov-2013 Alan Viverette <alanv@google.com> Add methods for removing children and actions from A11y nodes

BUG: 11421730
Change-Id: Ide396e6a0fec871395a9cadf8880c16d0de08294
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
96844ed886cc887a34bfc2fd04fc569d9c098623 18-Oct-2013 Scott Main <smain@google.com> fix javadoc link

Change-Id: I509fb12393ee0b8bf78ff4110fc18420739f7c58
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
77e9a28e2faa36f127231b842476d47f9823a83a 13-Sep-2013 Alan Viverette <alanv@google.com> Add live region politeness to View, AccessibilityNodeInfo

Alters the content change API to contain a bit mask of types of
changes represented by the event. Live regions send CONTENT_CHANGED
events immediately. Removes unused APIs for EXPANDABLE/EXPANDED.

BUG: 10527284
Change-Id: I21523e85e47df23706976dc0a8bf615f83072c04
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
6685f1bacead5f765c71a49f5cf0dc88750344d5 09-Sep-2013 Svetoslav Ganov <svetoslavganov@google.com> AccessibilityNodeInfo incorrectly cloned.

The code that creates a clone of an AccessibilityNodeInfo was not cloning
the extension objects (CollectionInfo, CollectionItemInfo, and RangeInfo)
and as a result if the original accessibility node info is recycled the
extension objects of the clone are also recycled and now if one tries to
recycle the clone gets an exception that the extension objects are already
recycled. Fun!

bug:10642952

Change-Id: I84192466bff0e865de04b79079e6ceecdffb37a6
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
cb8ed39b3fb591be60b9fb1799d4ea4530eab758 24-Aug-2013 Svetoslav Ganov <svetoslavganov@google.com> Update AccessibilityNodeInfo API as per API council request

bug:10461302

Change-Id: I9709a271ab3720e064b98c79c0950d811fe37b73
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
df39cb9b05a223f24b43c783574abbe67d643fdb 19-Aug-2013 Alan Viverette <alanv@google.com> Remove duplicate sealed node checks, add missing checks

Change-Id: Icbe79ba4b74776f845b43f261624d0dbeda4250b
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
3fcf1eda18f6c6ce2bf8f9ba7c09ca973b917009 18-Jun-2013 Svetoslav <svetoslavganov@google.com> Update Javadoc references

Change-Id: I2e4834070de6ebd55e6350f31f9f8e619cb0ff2d
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
3577a283e1af3e14fe980c4fec55781a58cd8e3c 06-Jun-2013 Svetoslav <svetoslavganov@google.com> Adding traits APIs to AccessibilityNodeInfo.

This change adds several traits and properties to AccessibilityNodeInfo
aiming to allow better description of native Android components to
accessibility services as well as mapping web content to native Android
node info tree.

Change-Id: I36b893cbaa6213c9d02d805e9dc36b6d792b4961
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
6254f4806dd3db53b7380e77fbb183065685573e 05-Jun-2013 Svetoslav <svetoslavganov@google.com> Optimizing AccessibilityNodeInfo caching.

1. Before we were firing an accessibility event from the common
predecessor of views with accessibility related state changes
every X amount of time. These events designate that the tree
rooted at the source is invalid and should not be cached.
However, some of the state changes do not affect the view tree
structure and we can just refresh the node instead of evicting
and recaching nodes infos for views that did not change. Hence,
we need a way to distinguish between a subtree changed over a
node changed.

Adding a new event type will not work since if say two siblings
have local changes and their predecessor fires a window state
change event, the client will drop the subtree rooted at the
parent including the two views with changes. Subsequent, more
specialized events emitted from the two changed siblings will
be useless since the parent which did not changed is already
evicted from the cache. Conversely, if the specialized events
are fired from the two siblings with local changes and they
are refreshed in the cache the subsequent window state change
event from the common predecessor will force the refreshed
nodes to be evicted.

Hence, to enable distinction between node being changed and
a subtree baing changed while not changing existing behavior,
we will fire only window content change event with an additional
argument specifying what changed - node or a subtree for now.
Also if the changes are local to a view we fire the window
content changed event from the view. So, the two siblings will
fire such an event independently and the client will know that
these are local changes and can just refresh the node. If the
changes are structural, then we fire the window state change
event from the common predecessor.

2. Added the input type of a text view as one of the properties
reported by an AccessibilityNodeInfo. It is nice to prompt the
user what input is expected.

3. Added a bundle for optional information to AccessiiblityNodeInfo.
For example, it will be used for putting web specific properties
that do not map cleanly to Android specific ones in WebView.

4. AccessibilityInteractionController was not taking into account
whether the current accessibility focused node is shown before
returing it. Hence, a disconnected node would be returned and
caching it puts our cahche in an inconsistent state.

Change-Id: I8ed19cfb4a70bdd7597c3f105487f1651cffd9e0
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
9fa1ee563b5a9ca25554f1fa59d1222dcfdfc623 22-Apr-2013 Svetoslav <svetoslavganov@google.com> Making new node id APIs return strings.

The node id does not have to be decorated with spans like spannable
so it makes no sense to have these APIs use anything else but string.

bug:8657338

Change-Id: I2e7c31128ee9f2933bd0d58beac4ba31a498bb09
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
bcc46a0d037e62fcb5e5f0f5e1acef5a8c1314b0 06-Feb-2013 Svetoslav <svetoslavganov@google.com> Set accessibility cursor in non-text views with content description.

We support text traversal at a granularity over non-next views with
content description, hence we should support setting the cursor position
in such views.

bug:8134469

Change-Id: I4dba225b0ade795b7a20c201fb906ae7146c065d
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
92826459d101d2d76b2d75347232b1fee08962cf 05-Feb-2013 Svetoslav <svetoslavganov@google.com> Fix a javaDoc error

Change-Id: Ia23660f102455aefad80cb75a8bbd8fc0d4455c3
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
22431a3b6fb5ae3498c6ae780648ca0228635eba 05-Feb-2013 Svetoslav <svetoslavganov@google.com> Rename a member variable

Change-Id: I1f7a3b8119d84a1119637f79fcd3c29f8b79ef27
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
eecedffe4286321c3a4e58ef66a536420cd1f239 05-Feb-2013 Svetoslav <svetoslavganov@google.com> Renaming some APIs

Change-Id: I9e226d39648796f95dd0e86ffecbb3f93544243b
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
242724ee524573b42cad3812c633295607f9c6e1 01-Feb-2013 Svetoslav Ganov <svetoslavganov@google.com> Add to string implementation for the new accessibility actions.

bug:8122974

Change-Id: I3d0907af37a6622ab867317e67c773a8aeb16abf
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
7c51284d8019ed04ab296be84839d8a90ac042fa 31-Jan-2013 Svetoslav <svetoslavganov@google.com> Add accessibility actions for text editing.

Currently text editing is pretty hard (certain operations even
impossible) for a blind person. To address the issue this change
adds APIs that enable an accessibility service to perform basic
text editing operations such as copy, paste, cut, set selection,
extend selection while moving at a given granularity.

The new APIs enable an accessibility service to expose a gesture
driven efficient text editing facility.

bug:8098384

Change-Id: I82b200138a3fdf4c0c316b774fc08a096ced29d0
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
14ff996ce82734100ba3faedbc80c4783eebea9d 29-Jan-2013 Svetoslav <svetoslavganov@google.com> Update JavaDoc

Change-Id: I9644677eb715de1c4ba2f1608b38980f02bdf75d
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
80943d8daa6ab31ab5c486d57aea406aa0730d58 02-Jan-2013 Svetoslav Ganov <svetoslavganov@google.com> Adding UI test automation APIs.

This change adds APIs support for implementing UI tests. Such tests do
not rely on internal application structure and can span across application
boundaries. UI automation APIs are encapsulated in the UiAutomation object
that is provided by an Instrumentation object. It is initialized by the
system and can be used for both introspecting the screen and performing
interactions simulating a user. UI test are normal instrumentation tests
and are executed on the device.

UiAutomation uses the accessibility APIs to introspect the screen and
a special delegate object to perform privileged operations such as
injecting input events. Since instrumentation tests are invoked by a shell
command, the shell program launching the tests creates a delegate object and
passes it as an argument to started instrumentation. This delegate
allows the APK that runs the tests to access some privileged operations
protected by a signature level permissions which are explicitly granted
to the shell user.

The UiAutomation object also supports running tests in the legacy way
where the tests are run as a Java shell program. This enables existing
UiAutomator tests to keep working while the new ones should be implemented
using the new APIs. The UiAutomation object exposes lower level APIs which
allow simulation of arbitrary user interactions and writing complete UI test
cases. Clients, such as UiAutomator, are encouraged to implement higher-
level APIs which minimize development effort and can be used as a helper
library by the test developer.

The benefit of this change is decoupling UiAutomator from the system
since the former was calling hidden APIs which required that it is
bundled in the system image. This prevented UiAutomator from being
evolved separately from the system. Also UiAutomator was creating
additional API surface in the system image. Another benefit of the new
design is that now test cases have access to a context and can use
public platform APIs in addition to the UiAutomator ones. Further,
third-parties can develop their own higher level test APIs on top
of the lower level ones exposes by UiAutomation.

bug:8028258

Also this change adds the fully qualified resource name of the view's
id in the emitted AccessibilityNodeInfo if a special flag is set while
configuring the accessibility service. Also added is API for looking
up node infos by this id. The id resource name is relatively more stable
compared to the generaed id number which may change from one build to
another. This API facilitate reuing the already defined ids for UI
automation.

bug:7678973

Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
0b0afb49a85c54b6e876055e76dc41d4345948a4 04-Dec-2012 Svetoslav Ganov <svetoslavganov@google.com> Adding API for refreshing the state of an AccessibilityNodeInfo.

Sometimes a client needs to hold onto an accessibility node info and
this info may get into a stale state. The clent has to be able to
request a refresh of the info. This change adds a refresh call to
AccessibilityNodeInfo.

bug:6711796

Change-Id: I580a9a5d9fd1f705ea0a2cf4d3ff65543714c9c3
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
f4782ec9c57a40224ac0974fce6b6fe280c829ce 28-Nov-2012 Svetoslav Ganov <svetoslavganov@google.com> Switching the accessibility poolable classes to the new pool management APIs.

The pool management APIs were simplified and using them requires much less
code than implementing your own pooling. Using common pooling logic is
also less error prone. This change swithces AccessibilityEvent and
AccessibilityNodeInfo to the new APIs.

Change-Id: I2dcfe2e1b0b0be5f89bd92359766ae3d6f8a143b
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
33aef98fd28dcac0a2ad37e7329afd3e666f5e0a 13-Sep-2012 Svetoslav Ganov <svetoslavganov@google.com> Allowing association between a view and its label for accessibility.

1. For accessibility purposes it is important to be able to associate
a view with content with a view that labels it. For example, if
an accessibility service knows that a TextView is associated with
an EditText, it can provide much richer feedback.

This change adds APIs for setting a view to be the label for another
one and setting the label for a view, i.e. the reverse association.

bug:5016937

Change-Id: I7b837265c5ed9302e3ce352396dc6e88413038b5
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
c9c9a48e7bafae63cb35a9aa69255e80aba83988 16-Jul-2012 Svetoslav Ganov <svetoslavganov@google.com> Removing a workaround for incorrect window position on window move.

1. The window manager was not notifying a window when the latter
has been moved. This was causing incorrect coordinates of the
nodes reported to accessibility services. To workaround that
we have carried the correct window location when making a
call from the accessibility layer into a window. Now the
window manager notifies the window when it is moved and the
workaround is no longer needed. This change takes it out.

2. The left and right in the attach info were not updated properly
after a report that the window has moved.

3. The accessibility manager service was calling directly methods
on the window manager service without going through the interface
of the latter. This leads to unnecessary coupling and in the
long rung increases system complexity and reduces maintability.

bug:6623031

Change-Id: Iacb734b1bf337a47fad02c827ece45bb2f53a79d
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
27e2da7c171afa39358bbead18fbe3e6b8ea6637 03-Jul-2012 Svetoslav Ganov <svetoslavganov@google.com> Remove the accessibility focus search code.

1. In JellyBean we have added some APIs to search for next accessibility
focus in various directions and set accessibility focus from hover.
However, we have decided that there is not clean answer for how this
should behave and the APIs were hidden. Now the accessibility service
is responsible for that. The unused code is now taken out.

2. This patch also takes out the hidden attribute accessibiligyFocusable
since we moved the responsibility for implementing focus search strategy
to accessibility services and we did not need that for Jellybean which
is a good sign that this is not needed. I general this is one less thing
for an app developer to worry about. We can add this if needed later.

bug:6773816

Change-Id: I0c858d72c93a2b7ff1f8f35a08d33ec4b9eb85fd
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
8ffe8b304e4778b3c95e57ad5a77cd41c9cf9f7b 15-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Accessibility focus search and setting it from hover are performed by the client.

1. Currently we are providing accessibility focus search algorithm in the
framework and we are also setting accessibility focus from hover. It
appears that implementing a focus search strategy that works for all
accessibility services is non trivial task if feasible. Based on
feedback from the developers of two such services at Google - TalkBack
and BarilleBack - the built in focus search does not quite match what
they need and they would like to implement a custom strategy.

Hence, having APIs for accessibility focus search in the framework does
not make. Therefore, we are hiding this APIs and later will take out the focus
search logic and allow the accessibility service to implement search.

Also putting accessibility focus from hover is tightly integrated with
the focus search since the set of views that get accessibility focus
from hover should be the same as the set of views returned by the
focus search routine. Therefore, we are letting the accessibility service
decide where to put accessibility focus when it gets an accessibility
hover event.

bug:6675330

Change-Id: Ie152230990a6602f3fd1d82de2177d0b1444d654
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
ee33ad24cdc31ed0d7f99e110e041b0a63c9b0f1 09-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Settings crash after enabling TalkBack accessibility.

1. AccessibilityInput filter was not checking whether the touch
explorer instance is not null before passing it an accessibility
event. If the accessibility event is dispatched before the input
filter is installed but after it is created we runt into this
case.

2. Added a missing null check in accessibility node info.

bug:6635089

Change-Id: Ia389dc1f427427eb73794f6331ccb870e0b44c55
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.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/core/java/android/view/accessibility/AccessibilityNodeInfo.java
2ef6905003c20010032ee993dfcc5899ad9be6f8 04-Jun-2012 Svetoslav Ganov <svetoslavganov@google.com> Client app crashes if accessibility service uses invalid focus type.

1. If an accessibility service uses an invalid focus type argument
when trying to find where focus is the queried application crashes.
The same happens if the serivce calls focus search with an invalid
derection. While we need the argument check in the controller that
runs in the app process the accessibility service has to be the
palace where an exception is thown for the invalid argument so
the developer can fix his code.:

bug:6508797

Change-Id: Ib0d74f374fa60ee8fd6117f11c23af34f6c26ad3
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.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/core/java/android/view/accessibility/AccessibilityNodeInfo.java
6704c233390743890d23338a2329dcda5709b810 08-May-2012 Svetoslav Ganov <svetoslavganov@google.com> Merge "AccessibilityNodeInfo for visible views should reported." into jb-dev
0a1bb6dffc358c01e10555c5c833edb7dba69659 07-May-2012 Svetoslav Ganov <svetoslavganov@google.com> AccessibilityNodeInfo for visible views should reported.

1. AccessibilityNodeInfos for visible views should always
be reported and the clients should be able to check
whether that node info is shown to the user. For example,
focus search may return a node that is not on the screen
and the accessibility layer may decide to give it focus
which scroll the source view in the screen.

bug:6421991

Change-Id: Idc1fd8512dda767abe802aacedb0c69582e6fc2a
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
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/AccessibilityNodeInfo.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/AccessibilityNodeInfo.java
e9bda15f87c11a8827ca0ffc865611176805cc0a 01-May-2012 Svetoslav Ganov <svetoslavganov@google.com> AccessibilityNodeInfo.getActionSymbolicName() is missing A11y focus actions.

1. The new actions were not added to this helper method so it was
throwing an InvalidArgumentException.

bug:6421059

Change-Id: I132348a50bb900ee19b95cc92c26ce47609ccb1c
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.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/AccessibilityNodeInfo.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/core/java/android/view/accessibility/AccessibilityNodeInfo.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/core/java/android/view/accessibility/AccessibilityNodeInfo.java
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/core/java/android/view/accessibility/AccessibilityNodeInfo.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/view/accessibility/AccessibilityNodeInfo.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/AccessibilityNodeInfo.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/AccessibilityNodeInfo.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/view/accessibility/AccessibilityNodeInfo.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/core/java/android/view/accessibility/AccessibilityNodeInfo.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/core/java/android/view/accessibility/AccessibilityNodeInfo.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/view/accessibility/AccessibilityNodeInfo.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/AccessibilityNodeInfo.java
ec6c89b616f5ae50f26185e14ef0f104f7e3f956 27-Oct-2011 Svetoslav Ganov <svetoslavganov@google.com> Merge "Minor documentation fixes for the APIs to expose virtual view tree."
af0d984a5850666a374d6f7fc690664d33d57568 27-Oct-2011 Svetoslav Ganov <svetoslavganov@google.com> resolved conflicts for merge of b0267e28 to master

Change-Id: Ic65ab83958b2e6bb941fe015b557fd2fd8f80683
c0291bb2eb96e96e0fe06047be929f89aa985ae6 26-Oct-2011 Svetoslav Ganov <svetoslavganov@google.com> AccessibilityNodeInfo makes incorrect check before calling into the system.

AccessibilityNodeInfo#getParent is checking whether the source view
accessibility id is specified instead that of the parent.

bug:5505799

Change-Id: I436fd2327def2762b4d307819ba0c23baa9a4e03
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.java
71b4e71c67df79f53b582fabb34b96ddbe23fe0f 25-Oct-2011 Svetoslav Ganov <svetoslavganov@google.com> Minor documentation fixes for the APIs to expose virtual view tree.

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

Change-Id: Ice8cf9ac6918b3bfa553776c68d4619fa6559cf8
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.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/AccessibilityNodeInfo.java
86398bda3dd869c67faa841a5d961316b5f4aa8a 22-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> AccessiblityNodeInfo#findAccessibilityNodesByText returns null if non found.

1. Updated the code to return empty list instead.

2. Updated the doc to explain that the search is done in the
sub-tree rooted at the info whose method is called.

Change-Id: I560d2563ed4772305bf2d7919560ef19baa30a1d
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfo.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/AccessibilityNodeInfo.java
8dffad68c7aa7da9a3d73d1ee41f3c4460f733b4 10-Jun-2011 Svetoslav Ganov <svetoslavganov@google.com> Bug fixes in the accessibility interrogation APIs

1. AccessibilityNodeInfo was not overriding equals.

2. ViewAncestor was not calling the callback for
setting the result of an interrogation request
thus making the system process wait upto the
maximal timeout.

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