ded133c446fa9d0d23e6bde19a66fb2ce3980491 |
|
31-Jan-2015 |
Svetoslav <svetoslavganov@google.com> |
Fix broken activation of the selected view in accessibility mode. We were using an approximation to determine where to send a pair of down and up events to click on the view that has accessibility focus. We were doing reverse computation to figuring out which portion of the view is not covered by interactive views and get a point in this region. However, determining whether a view is interactive is not feasible in general since for example may override onTouchEvent. This results in views not being activated or which is worse wrong views being activated. This change swithes to a new approach to activate views in accessibility mode which is guaranteed to always work except the very rare case of a view that overrides dispatchTouchEvent (which developers shouldn't be doing). The new approach is to flag the down and up events pair sent by the touch explorer as targeting the accessibility focused view. Such events are dispatched such that views predecessors of the accessibility focus do not handle them guaranteeing that these events reach the accessibiliy focused view. Once the accessibiliy focused view gets such an event it clears the flag and the event is dispatched following the normal event dispatch semantics. The new approach is semantically equivalent to requesting the view to perform a click accessiblitiy action but is more generic as it is not affected by views not implementing click action support correctly. bug:18986806 bug:18889611 Change-Id: Id4b7b886c9fd34f7eb11e606636d8e3bab122869
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
10a053e474e2a566b49a1e4c9e2ec4c8cc0013bd |
|
23-Jan-2015 |
Svetoslav <svetoslavganov@google.com> |
Accessibility: Sometimes cannot interact with nav bar items. If there is a window with the accessibility focus we want to click on the accessibility focused view in this window. The logic to compute the bounds of the window was using the wrong window id, hence getting an incorrect result. As a consequence in some cases the user could not click on accessiiblity focused controls in the nav bar. bug:18889611 Change-Id: I89aee3ae2ffe27fe29819049c287a7155154c65b
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
14e3351a1eae2b4fc8a12c9a4586f8ea7b87442c |
|
12-Dec-2014 |
Svet Ganov <svetoslavganov@google.com> |
Merge "Fix a NPE in AccessiiblityManagerService." into lmp-mr1-dev
|
09687064f4cf681d2aa299c393e32f22fc013c96 |
|
12-Dec-2014 |
Svet Ganov <svetoslavganov@google.com> |
Fix a NPE in AccessiiblityManagerService. It is possible that the accessibility windows list is null which is treated as if there is no window information. The getWindows method was accessing properties of the windows filed witgout a null check. bug:18522998 Change-Id: Ieefe678d3da3d6e8f96c0e4bedac0c55975621fa
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
12b7328c0b7f83a233d9387eaa66d1a0ed403724 |
|
09-Dec-2014 |
Svet Ganov <svetoslavganov@google.com> |
Ignore accessibility overlay when computing window's interactive region. If an accessibility service opts-in for the new window introspection APIs when calling into a window for accessibility node infos we compute the window's interactive region, i.e. the portion that is touchable and not covered by other touchable windows, in roder to deterine whether these nodes are visible, i.e. the user can interact with them. There was a bug in the interactive region computation what we were not ignoring accessibility overlay windows which are intended to not change what an accessibility service can "see" and are put by such a service. bug:18652374 Change-Id: I24ce54069087af9bc308e0c6a7b2aa6b952a6136
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
3a0d878ab56475276c61d574af7651820a5cea5a |
|
04-Dec-2014 |
Svetoslav <svetoslavganov@google.com> |
Ensure all events from a showing window are dispatched. Accessibility services may opt-in to introspect the interactive windows on the screen. If window introspection is enabled there is a case where some events from a showing window are received before the updated window state from the window manager. Now the window manager sends over the windows before notifying the app for the focus change. bug:18625996 Change-Id: Ic481e01efbe12dc92f090f799feeb236672fc7b3
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.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/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
5f978bfa0949d58a187dec0fe9ee6b341cb97c1f |
|
20-Oct-2014 |
Adrian Roos <roosa@google.com> |
Merge "Retire RecentApplicationsDialog" into lmp-mr1-dev
|
5d6041813283086c5a290ad6ca07e05b1a6ffc14 |
|
18-Oct-2014 |
Kristian Monsen <kristianm@google.com> |
Merge "Let TYPE_ANNOUNCEMENT be sent from any window" into lmp-dev
|
a6711ff6f09cc25c693cbb50452e3f807c6122f5 |
|
17-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
Accessibility no longer overrides strong encryption. Updating the accessibility layer behavior to reflect the new model where accessibility no longer overrides strong encryption. Now enabling an accessibility service lowers the encryption level but the user can bump it up in settings if desired. bug:17881324 Change-Id: Ic60d760c267d3f934040a42e1963b179bd8b9f5f
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
ba3787d849610a7c71fc6f0d9468855c3d369807 |
|
17-Oct-2014 |
Kristian Monsen <kristianm@google.com> |
Let TYPE_ANNOUNCEMENT be sent from any window Part of fix for bug 17905712 Change-Id: I4e4b09f6b6342a27744e42984d483ef8de18fbff
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
d5b0842a1ddbfc2ea5335854fe2834b6e9b965de |
|
16-Oct-2014 |
Svet Ganov <svetoslavganov@google.com> |
Send accessibility events with no window. An app can send an accessibility event by calling the send methods on view or directly asking the accessibility manager to do that. While the recommened way to send such events is calling the methods on view a legacy app or app whose developer did not read the docs carefully may be calling the accessibility manager APIs directly. In such a case the event does not have assigned window id and does not get send. Since events fired by using the accessibility manager directly lack context to determine whether thier source is important for accessibility we assume they come from an important view to avoid breaking backwards compatibility. bug:18001711 Change-Id: Ie1c298fa5a0670cbeaedfcd64f820961c296b6ca
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
9a64513c7fccc2a9cf331a384906a7669b29b3f4 |
|
08-Oct-2014 |
Adrian Roos <roosa@google.com> |
Retire RecentApplicationsDialog Bug: 5162991 Change-Id: I429da977502f33e2091496f3a075b2c507a88e1f
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
8ff6d70d44626cd515f517962378d89ab3954979 |
|
04-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
Merge "Clear identity before calling into the mount service." into lmp-dev
|
9f70a4cc6dbdd7b509527cef892e8af3c8b09702 |
|
04-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
Clear identity before calling into the mount service. bug:17787265 Change-Id: I4b9268d101e9ccfc30876fbf54bf28bb41fb4be6
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
47b9c1524fe20b9ae2b210acdcad64f764df68e0 |
|
04-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
TouchExploer computes incorrectly the click location. If there is accessibilty focus and the user touch explores location that does not change accessibility focus that is not in the app window, e.g. system bar, double tap does not click on the system UI affordance. bug:17588024 Change-Id: I6c8c0f65b208ae1d3f31d7f06b0721dc223ec19f
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
76716c5a180aa471c6973ca7aa03c7f2da677823 |
|
03-Oct-2014 |
Svetoslav Ganov <svetoslavganov@google.com> |
Revert "TouchExplorer computes incorrectly the click location." This reverts commit 851a5059a47cbf76e530c9d050a677cb6e3f8657 as it creates a regression. Let us revert this and correctly fix the issue the original change was trying to address. bug:17789608 Change-Id: I8abb1a61d5310430e839e4ef60e7ca5cc0cbdd80
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
d35b072dca42d249c219c886322c122739b086d7 |
|
02-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
Merge "Fix accessiblity introspection from the shell user regression." into lmp-dev
|
ceac51deddb873956c647d1b2dc7b2cc251d404b |
|
01-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix accessiblity introspection from the shell user regression. Accessibility introspection APIs are meant to query only the state of the current user. There are command line tools that run as the shell user and want to be able to intropspect the screen. When resolving the calling user we were using the calling user id instead of the special constant for the current user. Now when resolving the calling user for intrspection we are using the current user constant and consequentially only the current user or a profile of the current user or the root or the shell or the system or an app with cross user permission can introspect the screen. bug:17674631 Change-Id: I36d1d7b65441d04c3b4204123c4b6d036ff032c0
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
6b491b64ba7200a85199452b6a7f99c777105f22 |
|
01-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
Merge "Invalid accessibility state if UI test process crashes in a bad time." into lmp-dev
|
419036b560e79c11705e376ad171688ac496bb7d |
|
01-Oct-2014 |
Svetoslav <svetoslavganov@google.com> |
Invalid accessibility state if UI test process crashes in a bad time. We allow a fake accessibility service to connect to the system for UI automation. If the process hosting the fake service dies right after registering it, the accessibility layer ends up in a bad state and subsequent attempts to connect UI automation service fail. bug:17725904 Change-Id: Idad288eab41bbdd486d95e1e5803220640653fb7
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
16e4a1aade2b73edfdaa42aa86a3893fd039fc62 |
|
30-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Use default encryption password if an accessibility service is enabled. When device is encrypted the user has to authenticate in order to decrypt the data partition which is required for running accessibility services and Text-To-Speech. In order to address this issue we are falling back to use the default password if there is an enabled accessibility service and the user has secure lock. This will enable the user to authenticate when accessibility layer is completely functional. bug:17671790 Change-Id: Iafffe7bcd234008cf91ffb5011b21b803dca227a
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
54b0a05b00226c2c9064a61297857ae7d15fc4ed |
|
26-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Merge "Invalid active window if temporary disabling accessibility for test tools." into lmp-dev
|
3f92ffc369c31c98620e22b66366adb93c60a5f8 |
|
26-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Invalid active window if temporary disabling accessibility for test tools. If accessibility is enabled and a test tool based on the accessibility APIs connects to the system we suspend the current accessibility services while the tool is running (to avoid inteference as the tool is such a service) and after the tool disconnects we restore the accessibility state. The issue is that when clearing the accessibility state we were also wrongly clearing the active window. We are now careful to not clear the active window in such a case. It is also possible that the active window was never initilaized before the tool is run so now it is lazily loaded such that if we do not know which one it is, we get the one the has input focus. The definition of an active window is the one that has input focus or the user is touching. bug:17663432 Change-Id: I8868866a5126c590d3bddad099ababb97978227a
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
471157821f7b0933c55081ef4625c78f8e798de7 |
|
26-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Merge "Accessibility in bad state after using SDK tool uiautomatorviewer." into lmp-dev
|
dd81183bbea34109e1ae2d75667fe4784be6132f |
|
26-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Accessibility in bad state after using SDK tool uiautomatorviewer. The UiAutormator tool is a part of the SDK. If it is run while accessibility is enabled it stops all accessibility services as it is an accessibility service itself to avoid interference and when done restores back the accessibility state. The issue was that the accessibility state is not restored leaving the device in a bad state. bug:17662770 Change-Id: I3c4f46fa05c76b874eeffdeb867ef433c3fedf2e
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
8aeb0912945ae103223b76d81579073e51579efe |
|
25-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Accessibility events may be fired even if no services observe them. If all accessibility services are disabled we turn off event firing to avoid a lot of work for nothing. The logic to do that had a flaw and was not turning event firing off in every case it should. We were tuning event firing if it is on and no service is enabled but it is possible that a package on the system image is disabled so the service is enabled just not bound. Arguably we can remove the serivice from the enabled list but it is technically on the device. Note that we correctly handle the case of a package being removed. bug:17332506 Change-Id: I6d6d9cb9cc271116a3d22ed9fd8d7f533dec9a0b
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
8d412fe18b9ce8cf71ce57c380e7f312e4667667 |
|
20-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
TouchExploer computes incorectly the click location. If there is accessibilty focus and the user touch explores location that does not change accessibility focus that is not in the app window, e.g. system bar, double tap does not click on the system UI affordance. This is due to obsolete logic from the time where accessibility focus was only in the active window at the time of double clicking. bug:17588024 Change-Id: Ib780103e873d8a2afd3b35de3227d54116f1a1b0
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
4c6a4ce03bb5b20103a656948a1932f2894e7f56 |
|
18-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Some accessibility events wrongly filtered out (regression). We added new APIs to allow accessibility services to query all windows a user can touch. Sometimes the window state change event arrives before the window manager sent over the new window state which leads to a case that the app gets the event and asks for the window and the window is not there. To address this if we do not have the window, we hold on to the event and fire it as soon as the window arrives. This logic is correct except we were wrongly expecting that the window should have input focus. bug:17464645 Change-Id: I1ef50ebddeb4416a6c0776b096bb16aee703700c
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
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/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
9bf08c7bc1844ec8130b47d0ec3783f374b21c46 |
|
04-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Clear binder identity when sending window change accessibility events. We get calls for window changes from the window manager and as a result send accessibility events for these changes. It is possible that the call for a windows change from the window manager comes as a result of an unprivileged client calling into the window manager. However, the event sending code is performing security checks. bug:17364244 Change-Id: Ief016f9dafd13ac35418676817848b3ea3ed4d66
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
9ae9ed24aa252acbc2e6288068b991dd5291967b |
|
03-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix AccessibilityNode's isVisibleToUser behavior. The isVisibleToUser property of an AccessibilityNodeInfo specifies whether the user can see the source view. It is used by accessibility services to figure out whether to focus on a view. This property was giving a wrong value if the view is covered by another window such as the keyboard. As a result the user hears one thing but when double taps interacts with the overlaid window which is another thing. bug:15938254 Change-Id: Ib9feb20ea422a24a512c47ed1234961ae0386a7f
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.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/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.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/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.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/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
e34560b21989eea54a139a0586d156ba573cc2ea |
|
10-Jul-2014 |
Alan Viverette <alanv@google.com> |
Add accessibility action to open power long-press dialog Also fixes an infinite recursion bug in the WindowManagerService implementation of WindowManagerInternal. BUG: 16129909 Change-Id: I4f9d32f4e6c3ad460652c5e5271540fa5032a1f5
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
f7174e87b6007000777b0124de9cef70d8618788 |
|
12-Jun-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix backwards compatibility for introspected windows. 1. The APIs for introspecting interactive windows were reporting only the touchable windows but were missing the focused window. The user can interact with the latter by typing, hence it should always be reported. Also this was breaking backwards compatibility as if the focused window is covered by a modal one, the focused window was not reporeted and this was putting the active window in a bad state as the latter is either the focused window or the one the user is touching. 2. Window change events are too frequent as on window transition things are chanign a lot. Now we are trottling the windows changed events at the standard recurring accessibility event interval. 3. Fixed a wrong flag comparison and removed some unneded code. buy:15434666 bug:15432989 Change-Id: I825b33067e8cbf26396a4d38642bde4907b6427a
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
4604abc97d7dd757bb76ff9b7fcf343dc4a15212 |
|
11-Jun-2014 |
Svetoslav <svetoslavganov@google.com> |
Moving and resizing windows not reported propely for accessibility. When the position and size of a window changes we have to report that to the accessibility layer if the window introspection is enabled. bug:15569915 Change-Id: I3f869e0a582592bfa5f3743d5c2133ee8cb39b34
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
5c4cd189f298b3ddb9a5e8afc5f68546a9f96726 |
|
21-May-2014 |
Svetoslav <svetoslavganov@google.com> |
Fixing bugs due to the new custom accessibility action APIs. 1. AccessibiltiyAction was incorectly throwing an exception when a custom action was constructed. 2. AccessibilityManagerService should no longer enforce only standard actions as we allow custom ones too. bug:15110963 Change-Id: Iea57e0a6449b87bd8d103c55ca255e80705f2565
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
e08340645d2539ab13900b5f835b84bcfe8b99e0 |
|
13-May-2014 |
Alan Viverette <alanv@google.com> |
Simplify accessibility display adjustments Makes the inversion bit public so apps can be smarter about rendering images non-inverted (if they are so inclined). BUG: 14680114 Change-Id: I8ca2b2517af2ffc13446d7e0b4e859c1171e2d0e
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
0425d7f56b5c14484777357075b285d59996e6e9 |
|
08-May-2014 |
Svetoslav <svetoslavganov@google.com> |
Teach accessibility manager services about user profiles. For user profiles the accessibility layer will use the accessibility state of the their owner. A profile cannot have its own plugins or settings. The rationale behind this is that if a user with impaired vision is using the device with different profiles linked to his main one, then he/she should be able to interact with the device no matter what profile the app is being run with. Hence, The behavior of the accessibility features should be consistent across apps run with different profile. bug:14564491 Change-Id: Id19ce81e1a2dfa48015c7ab3053d66c058be3e46
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
02b9b981eae877a4624c1820f96298d88a5ced60 |
|
11-Apr-2014 |
Svetoslav <svetoslavganov@google.com> |
am 0f7ed1f4: Merge "Adding system support for a single accessibility focus." * commit '0f7ed1f4776844f3ee8d3ce9d903f62cace66a06': Adding system support for a single accessibility focus.
|
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/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
dd137a85d3e0295989b5b9d1f67ff32027be867d |
|
10-Apr-2014 |
Svetoslav <svetoslavganov@google.com> |
resolved conflicts for merge of 6be2f952 to master-lockscreen-dev Conflicts: core/java/android/view/IWindowManager.aidl tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java Change-Id: Idcbc581294cc52b53eabefd61e5c20cbcea611db
|
6be2f95202237b7284542e692273d13a5bd26913 |
|
10-Apr-2014 |
Svetoslav <svetoslavganov@google.com> |
Merge "Adding render stats APIs to UiAutomation (framework)."
|
6360d29cd78839539aafed961a0b96dc7ba3c317 |
|
10-Apr-2014 |
Svetoslav <svetoslavganov@google.com> |
am bc1a8f42: Merge "Active window not correctly computed." * commit 'bc1a8f42d9eb5f1d91c872904a9a283781291fcb': Active window not correctly computed.
|
48eacec53e3f877712c2cf66676f453ddf6b90fb |
|
10-Apr-2014 |
Svetoslav <svetoslavganov@google.com> |
Active window not correctly computed. The accessibility manager service was not handling the focused window properly which as a result was breaking the active window tracking. bug:13788022 Change-Id: Iaa3fadfbf7b9545f5151e3603beeda2662fe7618
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
1376d600d8e0eefdbc0aa11d398cf7517fc77129 |
|
13-Mar-2014 |
Svetoslav <svetoslavganov@google.com> |
Adding render stats APIs to UiAutomation (framework). bug:12927198 Change-Id: Iae21481c75ae58dcdab3731bf5f1e2844e29d434
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
380ecb81db52a9d0197ca969951d07b91c20d2b9 |
|
14-Mar-2014 |
Jorim Jaggi <jjaggi@google.com> |
Make Keyguard a library and make StatusBar the new Keyguard. This change achieves a couple of things: - Let Keyguard be a library, so we can use it in SystemUI. - Introduce FLAG_KEYGUARD for windows and deprecate TYPE_KEYGUARD. Make all the TYPE_KEYGUARD behaviour dependant on the flag. - Implement a new KeyguardService in SystemUI, and bind that service from PhoneWindowManager. - Introduce BaseStatusBar.setKeyguardState and inflate KeyguardSimpleHostView there and use FLAG_KEYGUARD for the window, such that the status bar window essentially gets the Keyguard. Bug: 13635952 Change-Id: I059d80d8b9b9818a778ab685f4672ea2694def63
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
cbcc9695f0a701d620f48de75eaee05c4fef6f22 |
|
26-Mar-2014 |
Svetoslav <svetoslavganov@google.com> |
Wrong constant used for undefined accessibility window id. Change-Id: I8b14db034a42a7ffd211a46fa3fee7bf2a6eac8f
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.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/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|
4cd353c038ec3c21f25c12897992e5e9826fe824 |
|
13-Feb-2014 |
Guang Zhu <guangzhu@google.com> |
add new accessibility action for EditText to set text content Bug: 12872344 Change-Id: I85a3805ab0c34b96a7d4228f2382c8ff664e36e8
/frameworks/base/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.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/services/accessibility/java/com/android/server/accessibility/AccessibilityManagerService.java
|