e5ea48a7fe295a2815bab57f2e870901ce48b312 |
|
29-Dec-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix a race in accessibility manager. The accessibility manager has APIs for clients to observe changes in accessibility, touch exploration, and high contrast states. The notification of the listeners has to be done with no lock held but in an attempt to do that the code was incorrectly iterating over the copy on write collection. bug:18840784 Change-Id: I6803ff1657fbf6b0cc7936671d5bbdebb5cbf6bb
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
c946f14a67f36d398f30040976ec6e7baf2643ac |
|
05-Aug-2014 |
Svet Ganov <svetoslavganov@google.com> |
Properly update accessibility manager state. Applciations that fire accessibility events have to first check it accessibility is on and then fire the event. If the app fires an event when the feature is off an exception is thrown. However, due to the way accessibility state is pushed to the local accessibility manager it was possible that the app checks that aaccessibility is off, fires an event, then the state of the local manager changes by the time the event is propagated up the view tree and an exception is thrown. This is a regression. We really want this exception to prevent apps sending events across processes if accessibility is off, so now the state we get from the system manager service is applied via a message so if the app checks that accessibility is off, then it will remain off (locally) until the event is propagated. bug:16672964 Change-Id: Icf5d1b1bdff87b58f285f0d9e1a098552513bbe8
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
cce47eb580d666ead1f6095d1e3b65233592bbaa |
|
17-Jul-2014 |
Chris Craik <ccraik@google.com> |
Add accessibility text contrast setting b/14624452 Adds a feature which draws all text (in the HW accelerated standard path) in a high contrast mode. Text is drawn at full alpha, and either white or black (depending on its original color) with a starkly contrasted outline beneath it. Change-Id: I943f624b6367de35367cced3b2a8298f2bc62377
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
576b6f2c25ab388e9dbc3bfc4df445ca648e7253 |
|
20-Mar-2014 |
Baligh Uddin <baligh@google.com> |
Fix Build
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
a053d095ae9d49aa22a0c717bb6ede687feb3fd2 |
|
20-Mar-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix build Change-Id: Icde98afd1471295320dc9042e1ecf680bb88ebd2
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.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/AccessibilityManager.java
|
49782e46c0eb85a25ae2abcf80880c48dbab5aea |
|
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
am 9158825f: Move some system services to separate directories * commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce': Move some system services to separate directories
|
9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories Refactored the directory structure so that services can be optionally excluded. This is step 1. Will be followed by another change that makes it possible to remove services from the build. Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
a393d6750ceb1b2508a77cedfd343d07bcebe43e |
|
10-Oct-2013 |
Alan Viverette <alanv@google.com> |
am 1cac53fa: am b8a140f3: am 1e2b6438: Merge "Fix accessibility state callbacks" into klp-dev * commit '1cac53fa63060ec3fa3b0249b941ccf8544b3333': Fix accessibility state callbacks
|
7e361d22e3ceb7dac79acd1cf3567de86eb045bc |
|
10-Oct-2013 |
Alan Viverette <alanv@google.com> |
Fix accessibility state callbacks BUG: 11141708 Change-Id: Ieff1fb90c4f894eba3c203089dd61e1dabdb7982
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
359404288c441904d636d48094669fcf66d49308 |
|
10-Oct-2013 |
Alan Viverette <alanv@google.com> |
am 9f57774e: am 972de252: am 24305da7: Merge "Add listener for changes to touch exploration state" into klp-dev * commit '9f57774ebb3b400b6597a9dbe854b4b6b1c8afd4': Add listener for changes to touch exploration state
|
5baeb9ad1e68cd1bdd0df0c14fe284a1660e2ee6 |
|
09-Oct-2013 |
Alan Viverette <alanv@google.com> |
Add listener for changes to touch exploration state BUG: 11141708 Change-Id: I353dfa2542ebd5e2ac89029dcd88623cc4c688e7
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
410d4e33c5542ccdeacdc8d0ac4aa0e194da688a |
|
01-Oct-2013 |
Alan Viverette <alanv@google.com> |
Add accessibility display adjustments BUG: 9057596 Change-Id: I5e7cc05159387cb00701e162d015e2f7ca6cbf4c
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
6b25e726cbe704a25a179ba62c6430dc6f974c67 |
|
01-Mar-2013 |
Svetoslav <svetoslavganov@google.com> |
Remove a workaround for accessibility managers that works across users. The system and some processes such as the keyguard and system UI run across users. Hence, the local accessibility manager should call into the backing system service with the id of the current user. For all other processes the local manager uses the current user id. There was a method that is to be called before the local accessibility manager has been accessed to initialize it to work across users. This had to be done for keyguard and system UI. This change removed the workaround and now the local accessibility manager determines under the hood which user id to use while calling into the system. If the local manager is in the system process or its process has permissions to work across uses, the manager uses UserHandle.USER_CURRENT, otherwise it uses the user if its process. Change-Id: I3e97fe98805adca01c1a0127a276828e90926f95
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
58d37b55bd228032355360ea3303e46a804e0516 |
|
18-Sep-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Multi-user support for the accessibility layer. 1. This change converts the accessibility manager service to maintain a state per user. When the user changes the services for the user that is going away are disconnected, the local accessibility managers in the processes for this user are disabled, the state is swapped with the new user's one, and the new user state is refreshed. This change updates all calls into the system to use their user specific versions when applicable. For example, regisetring content observers, package monitors, calls into other system services, etc. There are some components that are shared across users such as UI created by the system process and the SystemUI package. Such components are managed as a global state shared across all users and are updated accordingly on a user switch. Since the SystemUI is running in a normal app process this change adds hidden APIs on the local window manager to allow the SystemUI to notify the accessibility layer that it will run accross users. Calls to AccessibiltyManager's isEnabled(), isTouchExplorationEnabled() and sendAccessibilityEvent return false or a are a nop for a background user sice he should not send accessibility events, and should not perform touch exploration. Update the internal accessibility tests due to changes in the AccessibilityManager. This change also fixes several issues that were encountered such as calling out the accessibility manager service with a lock held. Removed some incorrect debugging code from the TouchExplorer that was leading to a system crash. bug:6967373 Change-Id: I2cf32ffdee1d827a8197ae4ce717dc0ff798b259
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.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/AccessibilityManager.java
|
b303d8381d734f48c4e1de4f11bf25950b28adf1 |
|
13-Oct-2011 |
Scott Main <smain@google.com> |
docs: a couple notes for a11y methods in View and cleanup to the A11y service HTML to be semantically correct and thus improve its accessibility :) Change-Id: I483a8a441d802b056f68f82e0e782d86a73298ac
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.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/AccessibilityManager.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/AccessibilityManager.java
|
4dfecf55c1afcc7ffe0cef931df67c4934a13e34 |
|
01-Jul-2011 |
Jim Miller <jaggies@google.com> |
Fix runtime reboot loop. Change-Id: Ib0614e64e81e376fdbbe7c42a5e4aa8fb9c88ce9
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
38e8b4e5bc3c93affdffbc064fd9db5aeccc3e8e |
|
30-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Updating accessibility documentation. Change-Id: Ice8cf9ac6918b3bfa553776c68d4619fa6559cf8
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.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/AccessibilityManager.java
|
cc4053e031371456fe54d51bbad1db721db4ae38 |
|
23-May-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility serviceconfiguration via meta-data Note: This is a part of two CL change and contains the system changes without updates to the settings. 1. Added a mechanism for configuring an accessibility service via XML file specified in a meta-data tag (similar to IMEs). 2. Added property for specifying a settings activity for an accessibility service. 3. Refactored the APIs in AccessibilityManager to return lists of AccessiblityServiceInfo instead ServiceInfo since the former describes an AccessibilityService in particular (similar to IMEs). Change-Id: Ie8781bb7e0cdb329e583b6702a612a507367ad7b
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
736c2756bf3c14ae9fef7255c119057f7a2be1ed |
|
23-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration feature, event bubling, refactor 1. Added an Input Filter that interprets the touch screen motion events to perfrom accessibility exploration. One finger explores. Tapping within a given time and distance slop on the last exlopred location does click and long press, respectively. Two fingers close and in the same diretion drag. Multiple finglers or two fingers in different directions or two fingers too far away are delegated to the view hierarchy. Non moving fingers "accidentally grabbed the device for the scrren" are ignored. 2. Added accessibility events for hover enter, hover exit, touch exoloration gesture start, and end. Accessibility hover events are fired by the hover pipeline. An accessibility event is dispatched up the view tree and the topmost view fires it. Thus predecessors can augment the fired event. An accessibility event has several records and a predecessor can optionally modify, delete, and add such to the event. 3. Added onPopulateAccessibilityEvent and refactored the existing accessibility code to use it. 4. Added API for querying the currently enabled accessibility services by feedback type. Change-Id: Iea2258c07ffae9491071825d966dc453b07e5134
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
3fb3d7c4e756bd32d5abde0abca9ab52d559bc84 |
|
23-Apr-2011 |
Adam Powell <adamp@google.com> |
Revert "Touch exploration feature, event bubling, refactor" This reverts commit ac84d3ba81f08036308b17e1ab919e43987a3df5. There seems to be a problem with this API change. Reverting for now to fix the build. Change-Id: Ifa7426b080651b59afbcec2d3ede09a3ec49644c
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
ac84d3ba81f08036308b17e1ab919e43987a3df5 |
|
05-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration feature, event bubling, refactor 1. Added an Input Filter that interprets the touch screen motion events to perfrom accessibility exploration. One finger explores. Tapping within a given time and distance slop on the last exlopred location does click and long press, respectively. Two fingers close and in the same diretion drag. Multiple finglers or two fingers in different directions or two fingers too far away are delegated to the view hierarchy. Non moving fingers "accidentally grabbed the device for the scrren" are ignored. 2. Added accessibility events for hover enter, hover exit, touch exoloration gesture start, and end. Accessibility hover events are fired by the hover pipeline. An accessibility event is dispatched up the view tree and the topmost view fires it. Thus predecessors can augment the fired event. An accessibility event has several records and a predecessor can optionally modify, delete, and add such to the event. 3. Added onPopulateAccessibilityEvent and refactored the existing accessibility code to use it. 4. Added API for querying the currently enabled accessibility services by feedback type. Change-Id: Iec03c6c3fe298de3f14cb6efdbb9b198cd531a0c
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
43a17654cf4bfe7f1ec22bd8b7b32daccdf27c09 |
|
07-Apr-2011 |
Joe Onorato <joeo@google.com> |
Remove the deprecated things from Config.java. These haven't been working since before 1.0. Change-Id: Ic2e8fa68797ea9d486f4117f3d82c98233cdab1e
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
af7adab3e35863fff24e701039d5d04afbc060c5 |
|
17-Apr-2010 |
Svetoslav Ganov <svetoslavganov@google.com> |
2604184 Expose hidden APIs for testing the AccessibilityManager separately from the backing AccessibilityManagerServcie Change-Id: Ief5df31baa3c0990467625977e97cd066a671959
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
dd64a9b0d6ff0f15b22d02a108c5342c74db995a |
|
14-Apr-2010 |
Svetoslav Ganov <svetoslavganov@google.com> |
2593833 AccessibilityManager not properly initialized immediately upon registration in the AccessibilityManagerService Change-Id: I0226bafc5e9c5b800c54019c9309394f1e5f9e88
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|
75986cf9bc57ef11ad70f36fb77fbbf5d63af6ec |
|
15-May-2009 |
svetoslavganov <svetoslavganov@google.com> |
Accessibility feature - framework changes (replacing 698, 699, 700, 701 and merging with the latest Donut)
/frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java
|