| 4528b4e882584745f48263fa6626987e63832a2a |
|
16-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Prefetching of accessibility node infos getting incorrect views.
1. The prefetcher of accessibility nodes infos was not folloing
the childForAccessibility relationship when finding the views
whose node infos to prefetch.
2. NumberPicker was not reporting the correct parent.
bug:6471710
Change-Id: Ia7ad5dd031fb4b3816dfe630d5212201cfafa236
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfoCache.java
|
| c406be9036643ebe41bafcd94fe4aa861b4e4f4f |
|
12-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix inconsitency in aAccessibilityNodeInfo cache.
1. Fixed errors in the accessibility node cache.
A. The cache was not catching the case when the current window changes as a
result the user touch exploring it. As a result the cache had nodes from
more that one window but the node ids are not unique thus causing a mess.
B. The node info tree was prefetched regardless if a prefetched node is root
name space (i.e. view ids - not accessibility ids - are namespaced) while
the prefetched nodes were taking this into account. As a result there can
get disconnected subtrees in the cache.
C. When an event for a property change such as focus was received the cache
we were removing the source node. As a result there may be disconnected nodes.
D. When a node was added to the cache and an older version exists there was
no check if it will point to the same children and parent. As a result if
the state of the node has fewer children the subtrees rooted at the no
longer present children will stay disconnected in the cache.
E. When a node got accessibility or input focus the old one in the cache was
not removed. As a result you may have a state with more than one access
or input focus.
2. Added integrity check enabled only on user builds when a specific flag is set
for the cache which checks whether:
A. All nodes are from the same window.
B. All nodes are connected.
C. There are no duplicates.
D. There is only one input focus.
E. There is only one accessibility focus.
3. The reported accessibility node info tree was stopping at the root namespace
boundary which is not correct. The reported tree has to reflect everything
on the screen that the user can see such a workspace with widgets. The root
namespace is added to avoid clash of view id but the accessibility ids are
unique no matter if the view is inflated from a remote view.
4. Added calls to notify the accessibility layer when a preoprty that is interesting
for accessibiliy has changed.
bug:6471710
Change-Id: I069470d91f209ba16313fa6539787a55efa3512e
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfoCache.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/AccessibilityNodeInfoCache.java
|
| afd5fab3ab001e90269dfef37d87e69e0e261826 |
|
24-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityNodeInfos node properly cached.
1. AccessibilityNodeInfo were not cloned when cached
and obtained from the cache. This was causing a
problem when the client calls #recycle() as he
should since this results in wiping the data of
the cached node info.
bug:6026952
Change-Id: I5807b09d95ef6f310327192ff91f036adf337e33
/frameworks/base/core/java/android/view/accessibility/AccessibilityNodeInfoCache.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/AccessibilityNodeInfoCache.java
|