27ad2e95b40fd0ca76de384695498ea114d627ca |
|
13-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Accessibility: Ensure fresh accessilbity focused and input focused nodes. Change-Id: Ia3c84284843a415cdbbc2b6a9b06d9ddffbe0e04
/frameworks/base/core/java/android/view/accessibility/AccessibilityCache.java
|
0322100598e3afae207bb98202b9ce53604bdb28 |
|
06-Dec-2014 |
Svet Ganov <svetoslavganov@google.com> |
Clear clicked nodes from the accessibiliy cache. Nodes that are clicked can change state as a result of a click, e.g. a check box. The accessibility service may decide to get the source node from the click event to probe its state and get a cached state since the window content changed event is after the click one. Therefore, we have to clear the state of the click event's source from the cache to ensure the client can query the latest state of that source. bug:18625975 Change-Id: I9e339c2fdcf74f260bb8ad86b9b873f7ddd75f19
/frameworks/base/core/java/android/view/accessibility/AccessibilityCache.java
|
13bd771c993f96a06add4057c5f5d5be7ac4b42a |
|
20-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix memory leak in accessibility cache. We were not clearing the cache if window state change event is fired which was the behavior before adding the window inspection APIs. As a result if no accessibility service cares about windows we get a leek. Also when the accessibiilty service cares about windows we were not clearing all windows nodes from the cache. Now if a windows change or a window state change event is recived we clear the cache. bug:17589257 Change-Id: I8c416fbcab623160c6f505128b9fca713fcc6623
/frameworks/base/core/java/android/view/accessibility/AccessibilityCache.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/AccessibilityCache.java
|
79dea425af818c3fe1d4edb0af7ad301cdd621a4 |
|
09-Aug-2014 |
Svet Ganov <svetoslavganov@google.com> |
Check accessibility cache integrity only on eng builds. The checks may have false ositives and spam test logs. bug:1689853: Change-Id: I576600192823f159e28ecea29f888187eeceb98b
/frameworks/base/core/java/android/view/accessibility/AccessibilityCache.java
|
a4725efd0bfa52cbddf6ca587d37fc4ebcbfaf72 |
|
24-Jul-2014 |
Svetoslav <svetoslavganov@google.com> |
Improve the window query API performamce. We are caching the window data in the accessibility service process. When windows change we were sending the dalta of the windows the service knows about. To make this work when the app asked for all windows we had to call into the system as new windows may have appeared. This was slow. Now we are telling the service some windows change and if it gets the windows we cache them. We call into the system only on a cache miss and evict all windows from the cache on window change event. We do not evict the nodes of the window as the former may have just moved. If views in a window change they fire accessibility events that trigger the correct eviction. Change-Id: I586a72a2497b0d44a75288fa758e7e88817f3300
/frameworks/base/core/java/android/view/accessibility/AccessibilityCache.java
|
f7c42c506796b8d828fbd1233edb9752a1f50e12 |
|
24-Jul-2014 |
Svetoslav <svetoslavganov@google.com> |
Updated accessibility nodes not properly cached. We have an accessibiliy node info cache in the process of each accessibility service. Sometimes the cached node changes and in this case we have evict from the cache the sub-trees rooted at children that are no longer present. There was bug where if none of the children is present anymore we did not evict their sub-trees. Also the verification logic was not stopping if a duplicate node is seen potentially getting into an infinite loop. bug:15729762 Change-Id: I7adf4f0a1bde07b385556d9acdded5059231f1f3
/frameworks/base/core/java/android/view/accessibility/AccessibilityCache.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/AccessibilityCache.java
|