History log of /frameworks/base/core/java/android/view/accessibility/AccessibilityWindowInfo.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
155edc693eecb64d821a95567e719d0de7ee9c85 09-Jun-2016 Phil Weaver <pweaver@google.com> Improve accessibility window title behavior

Un-reverts ag/1057448, but uses a version of Resources#getText
that returns null rather than throw an exception when no title
is available. This is the same call made before, so this change
should be safer.

Bug: 28744278
Change-Id: I8c123f4f6d74f796ab9e8ffcf955aaf881770da1
/frameworks/base/core/java/android/view/accessibility/AccessibilityWindowInfo.java
266ed9acc396ff007b75b8356429d703117de2d7 08-Jun-2016 Phil Weaver <pweaver@google.com> Revert "Improve accessibility window title behavior"

Bug: 29127065

This reverts commit 2a7e4442bf9892842e0fc7eba9296e8fcf9f8ea5.

Change-Id: Ibc5527cfedd49c685ffd1b8ae59e87ed99c93d39
/frameworks/base/core/java/android/view/accessibility/AccessibilityWindowInfo.java
2a7e4442bf9892842e0fc7eba9296e8fcf9f8ea5 20-May-2016 Phil Weaver <pweaver@google.com> Improve accessibility window title behavior

Suppress the default, unlocalized strings from being read as title.

Bug: 28744278
Change-Id: Iea0f7d8fed3d6428ada725cf3ffa077ba974b74a
/frameworks/base/core/java/android/view/accessibility/AccessibilityWindowInfo.java
396d549113bc633f719acc643c7dfc5f2a8fae4e 23-Mar-2016 Phil Weaver <pweaver@google.com> Add accessibility window title and anchor.

Plumbing through the title of windows so support multiwindow
accessibility.

Adding ability to determine the anchor of a pop-up window so the pop-up
can be traversed as part of its anchor.

Bug: 27687627
Bug: 8449376

Change-Id: I59e98a29fb90029407a26de5bf3d900fed5dd627
/frameworks/base/core/java/android/view/accessibility/AccessibilityWindowInfo.java
315c34e7d62ce4b609f2d08b18a11a2d44e93aba 20-Feb-2016 Phil Weaver <pweaver@google.com> Accessibility to toggle multiwindow mode

Encapsulating the logic to toggle multiwindow mode from recents,
and plumbing it through to accessibility global actions. Sending
accessibility events when windows bounds change. Exposing the
dock divider window type to accessibility services.

Bug: 27250995
Change-Id: Ib7491f1f853dc7f01bf5c5a4ac1f914f55d0608a
/frameworks/base/core/java/android/view/accessibility/AccessibilityWindowInfo.java
650989b0b5c6679c400db92017e9fafeb43b313e 16-Mar-2015 Andreas Gampe <agampe@google.com> Frameworks/base: Fix a comparison

Change-Id: I80d62869920e77110c95f20369ec2631c75f6ed4
/frameworks/base/core/java/android/view/accessibility/AccessibilityWindowInfo.java
3a5c721072c60c7ed9c8a95d0a65d0e3cb4eb9bb 14-Oct-2014 Svetoslav <svetoslavganov@google.com> APIs for an accessibility service to put interaction tracking overlays.

An accessibility service may register to observe the interactive windows
on the primary display. These windows are the one that has input focus and
ones a sighted user can touch. It is sometimes beneficial for an
accessibility service to overlay a window to intercept user interaction
and based on that introspect and perform an action on the windows that
are on the screen. This is problematic as overlaying a full screen window
that is touchable prevents the accessibility service to introspect the
content under this window.

This change adds a special type of window that only an accessibility service
can place which does not affect what an accessibility service can "see" on
the screen. Hence, even putting such a window full screen the service will
be able to interact with the other interactive windows it covers.

Change-Id: I053ccc3a5c6360a98dc40bdb172b54dab35d8b31
/frameworks/base/core/java/android/view/accessibility/AccessibilityWindowInfo.java
04cab1bcc46b05cbb72632c53ad83943f705b494 26-Aug-2014 Svetoslav <svetoslavganov@google.com> Fix accessiblity CTS tests (framework).

1. An external contribution changed the ordering of views for
accessibility. While it attempted to fix a platform issue
for a comparator breaking transitivity, it changed the way
we order views and results in very unnatural accessibility
traversal order. It also broke CTS tets. This change tweaks
the comparator which fixes the tests and improves traversal
order.

2. If there is at least one accessibility service which cares
about windows we register a callback in the window manager
for window change notifications. We are updating the window
list on this callback. There was a case where if the service
requests window updates and immediately asks for the windows
it gets none as we have not received a callback from the
window manager yet. Now this call returns after we get the
callback in a timed fashion. This is consistent with how the
other introspection APIs work.

3. Window info objects are cached in the accessibility service
process. When putting them in the cache a cloning call was
missing resulting in some cases of clobbering windows given
to the client. For example, we get some windows, cache them,
and return these windows to the client. Now a call to clear
the cache arrives while the user processes the windows and
the client windows get clobbered.

4. Added API for checking if a window has accessiblity focus
to be consistent to the API we have to check whether this
window has input focus.

5. Removed some obsolete code.

bug:16402352

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