7498efdc5e163d6b4a11db941c7d13c169d37284 |
|
04-Sep-2014 |
Svet Ganov <svetoslavganov@google.com> |
Clicking on partially coverd views by other views or windows. In touch exploration mode an accessibility service can move accessibility focus in response to user gestures. In this case when the user double-taps the system is sending down and up events at the center of the acessibility focused view. This works fine until the clicked view's center is covered by another clickable view. In such a scenario the user thinks he is clicking on one view but the click is handled by another. Terrible. This change solves the problem of clicking on the wrong view and also solves the problem of clicking on the wrong window. The key idea is that when the system detects a double tap or a double tap and hold it asks the accessibility focused node (if such) to compute a point at which a click can be performed. In respinse to that the node is asking the source view to compute this. If a view is partially covered by siblings or siblings of predecessors that are clickable, the click point will be properly computed to ensure the click occurs on the desired view. The click point is also bounded in the interactive part of the host window. The current approach has rare edge cases that may produce false positives or false negatives. For example, a portion of the view may be covered by an interactive descendant of a predecessor, which we do not compute (we check only siblings of predecessors). Also a view may be handling raw touch events instead of registering click listeners, which we cannot compute. Despite these limitations this approach will work most of the time and it is a huge improvement over just blindly sending the down and up events in the center of the view. Note that the additional computational complexity is incurred only when the user wants to click on the accessibility focused view which is very a rare event and this is a good tradeoff. bug:15696993 Change-Id: I85927a77d6c24f7550b0d5f9f762722a8230830f
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.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/AccessibilityInteractionClient.java
|
e16a5009cc02548266e483ee2456c631914519ac |
|
11-Jun-2014 |
Svetoslav <svetoslavganov@google.com> |
Accessibility window changes not reported. On accessibility service side we were asking only for cached windows but since to optimize performance the system is sending only deltas for windows the service already introspected, new windows were not seen by the accessibility service. bug:15092286 Change-Id: I7e9c360f624c53ff1773c485a8907dc425e3352a
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.java
|
6090995951c6e2e4dcf38102f01793f8a94166e1 |
|
19-Nov-2013 |
John Spurlock <jspurlock@google.com> |
Remove unused imports from frameworks/base. Change-Id: Ia1f99bd2c1105b0b0f70aa614f1f4a67b2840906
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.java
|
152e9bb81aa5b2ab4637f4b2dae04b3ce89fa891 |
|
13-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Refactoring of the screen magnification feature. 1. The screen magnification feature was implemented entirely as a part of the accessibility manager. To achieve that the window manager had to implement a bunch of hooks for an external client to observe its internal state. This was problematic since it dilutes the window manager interface and allows code that is deeply coupled with the window manager to reside outside of it. Also the observer callbacks were IPCs which cannot be called with the window manager's lock held. To avoid that the window manager had to post messages requesting notification of interested parties which makes the code consuming the callbacks to run asynchronously of the window manager. This causes timing issues and adds unnecessary complexity. Now the magnification logic is split in two halves. The first half that is responsible to track the magnified portion of the screen and serve as a policy which windows can be magnified and it is a part of the window manager. This part exposes higher level APIs allowing interested parties with the right permissions to control the magnification of a given display. The APIs also allow a client to be registered for callbacks on interesting changes such as resize of the magnified region, etc. This part servers as a mediator between magnification controllers and the window manager. The second half is a controller that is responsible to drive the magnification state based on touch interactions. It also presents a highlight when magnified to suggest the magnified potion of the screen. The controller is responsible for auto zooming out in case the user context changes - rotation, new actitivity. The controller also auto pans if a dialog appears and it does not interesect the magnified frame. bug:7410464 2. By design screen magnification and touch exploration work separately and together. If magnification is enabled the user sees a larger version of the widgets and a sub section of the screen content. Accessibility services use the introspection APIs to "see" what is on the screen so they can speak it, navigate to the next item in response to a gesture, etc. Hence, the information returned to accessibility services has to reflect what a sighted user would see on the screen. Therefore, if the screen is magnified we need to adjust the bounds and position of the infos describing views in a magnified window such that the info bounds are equivalent to what the user sees. To improve performance we keep accessibility node info caches in the client process. However, when magnification state changes we have to clear these caches since the bounds of the cached infos no longer reflect the screen content which just got smaller or larger. This patch propagates not only the window scale as before but also the X/Y pan and the bounds of the magnified portion of the screen to the introspected app. This information is used to adjust the bounds of the node infos coming from this window such that the reported bounds are the same as the user sees not as the app thinks they are. Note that if magnification is enabled we zoom the content and pan it along the X and Y axis. Also recomputed is the isVisibleToUser property of the reported info since in a magnified state the user sees a subset of the window content and the views not in the magnified viewport should be reported as not visible to the user. bug:7344059 Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.java
|
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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.java
|
fefd20e927b7252d63acb7bb1852c5188e3c1b2e |
|
20-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding an opt-in mechanism for gesture detection in AccessibilityService. 1. An accessibility service has to explicitly opt in to be notified for gestures by the system. There is only one accessibility service that handles gestures and in case it does not handle a gesture the system performs default handling. This default handling ensures that we have gesture navigation even if no accessibility service would like to participate/customize the interaction model. bug:5932640 Change-Id: Id8194293bd94097b455e9388b68134a45dc3b8fa
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.java
|
55cdacb9ba22ce0e40918fd54acca7df62637ca6 |
|
01-Dec-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 0bfdd7c2: am e9f24a43: Merge "Fix memory leaks in the accessibility layer." into ics-mr1 * commit '0bfdd7c2927fb683b89fdd52befe643e8e069e77': Fix memory leaks in the accessibility layer.
|
36bcdb535e14a8a2e2c8643fb577569f7a2b6aed |
|
01-Dec-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix memory leaks in the accessibility layer. The AccessibilityServiceConnection chache should be shared between all interrogating threads. bug:5664337 Change-Id: I151041d0b358e87ac47ea5c1c258f90a8b252420
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.java
|
786e54dd13111b6a2f75f4f37dd20353cf613e97 |
|
01-Dec-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing the build Change-Id: I125956773dd364b14f8d328e625df3c852001dbf
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.java
|
66922db828eab153c15bf3ca0b007313d9376e5e |
|
01-Dec-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing the build - for real Change-Id: I9628f2da8876b85f9c8ce94cc876b10e083980f6
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.java
|
8b5a814f6a36045b06bee36f44703503c03714d4 |
|
01-Dec-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing the build Change-Id: I7b2270843123b252098ca798c03284fb089f1b8a
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.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/AccessibilityInteractionClient.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/AccessibilityInteractionClient.java
|
6bc5e530016928027c7b390a8368ecdd5bff072f |
|
10-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Inter process interrogation ocassionally gets stuck. 1. There was a bug that was not handling correctly the case for which the interrogator requests an accessibility node info and the message describing how to fetch the latter for the same process case was delivered after the code that checks whether the message is there in order to dispatch it is executed. Now the message handling is done correctly - the caller checks if the message is present and if so processes it, otherwise the caller sleeps and is interrupted if such a message arrives. bug:5138933 Change-Id: I4c2940b46c9a52a51c5ee48b83ca6811489765d6
/frameworks/base/core/java/android/view/accessibility/AccessibilityInteractionClient.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/AccessibilityInteractionClient.java
|