b5e89c6debca90be92bf5bc2e0e79d109de6d08f |
|
02-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Support direct-boot tests. Add shell commands to check on current FBE status and system ready status. Mark variables without first-class locking as volatile. Fix bug where UI automation would crash while device was locked by marking it as forced direct-boot aware. Bug: 26498834 Change-Id: Ib4dfb9350925e5413f93a09baacf84c62f2ba0ea
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
8a372a0a280127743ce9a7ce4b6198c7a02d2a4f |
|
16-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Refactoring FBE APIs based on council feedback. Mostly consists of removing the word "encryption" from most APIs, since we can't actually make promises about the data being encrypted. Bug: 27531029 Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
e88e2665471c7b620fd3b1baca024fc9e705ee32 |
|
24-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Update accessibility to be encryption-aware. Look for both EA and non-EA accessibility services, but when the user is locked only bind to EA services. Once the user is unlocked, we take another pass and bind to any non-EA services. We only consider disabling accessibility once the user is unlocked, since there could be non-EA services waiting in the wings. Bug: 25860579 Change-Id: I97bd019661457c3577d629ba12290d02f026011a
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
a6b64f5099b7be6e8384958d8bcddb97bb06ec93 |
|
05-Dec-2015 |
Phil Weaver <pweaver@google.com> |
Gesture dispatch from accessibility services. Add public APIs to describe gestures and dispatch them from an accessibility service. Added a new capability that services must declare to have this capability. Bug: 22514086 Change-Id: I9bff2d9335f0310115112d14b7ed033a6d6c2393
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
214fb68767502f5fede643a062c1dc5975d75b27 |
|
17-Nov-2015 |
Alan Viverette <alanv@google.com> |
APIs for querying and controlling display magnification Also separates magnification state and touch event handling. Moves callbacks for window manager changes and display state changes into the magnification controller. Bug: 22718911 Change-Id: I3a8ba060a07d8f1f51856855a5f85601766fd45d
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.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/core/java/android/accessibilityservice/AccessibilityServiceInfo.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/accessibilityservice/AccessibilityServiceInfo.java
|
23be199171bedb05e81864f8941492af066fa667 |
|
03-Oct-2013 |
Alan Viverette <alanv@google.com> |
Add importantForAccessibility mode to block entire hierarchy Since older versions of the platform will crash if the mode is set to 3, this CL adds an extra bit and uses 4 as the mode. This will also cleanly default the mode to AUTO on unsupported platforms. BUG: 11031947 Change-Id: I48035abbf35523d65cead6f27be10f8087973ceb
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
00d17f7aab54ef055d35da603dab5a7bae751876 |
|
07-Jun-2013 |
Scott Main <smain@google.com> |
add attributes to accessibility service info Change-Id: I3651544164f718003b8eb1235a7d723f1bcee5be
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
11adf6dc2438260c3e0d79cc189bcb4f6f15e9f4 |
|
24-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
The touch exploration capability is dynamically granted pre-JellyBeanMR2. Since the enable touch exploration capability is dynamically granted by the user for apps targeting pre-JellybeanMR2 API level, we have to properly update the accessibility service info for that service and also avoid caching copies of the service info. bug:8633951 Change-Id: I83dd1c852706ec55d40cda7209ad842889fb970a
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
db7da0eb8b7d515c168d5b410764e24c9a0f9431 |
|
23-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
Fixing bugs exposed when moving accessibility CTS tests to UiAutomation. 1. UiAutomation#executeAndWaitForEvent method was invoking the passed runnable while holding the lock which may lead to a deadlock. For example: a runnable that calls getActivity() gets us into a state like this. 2. UI automation services did not get all capabilities such a service can have. Now a UI test service gets all of them. 3. When UiAutomation was exiting for event fired as a result of a performed action, it was checking whether the received evnet time is strictly before the time of executing the command that should fire the event. However, if the execution is fast enough, i.e. less than one millisecond, then the event time and the execution time are the same. This was leading to a missed signal in rare cases. 4. AccessibilityNodeInfoCache was not clearing the relevant state for accessibility focus clearing event. 5. Accessibility text traversal in TextView was partially using text and partially content description - broken. Now we are using the text since for text view and content desc for other views. In other words, we are using the most precise text we have. 6. AccessibilityManagerService was not granting capabilities of a UiAutomation service - plainly wrong. CTS change:https://googleplex-android-review.googlesource.com/#/c/300693/ bug:8695422 bug:8657560 Change-Id: I9afc5c3c69eb51f1c01930959232f44681b15e86
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
688a6977cf7673ed0542ab3d839053c4e38a4dbd |
|
17-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
Replacing accessibility service permissions with capability attributes. Accessibility services can perform special operations such as retrieve the screen content, enable explore by touch, etc. To ensure the user is aware that the service will perform special operations we were using permissions. However, the special operations cannot be performed unless the service is really enabled by the user and it is at this point that we want to notify the user about the service capabilities. This change adds capability attributes to the accessibility service's meta-data XML file. The service has to declare the capability and when it is enabled we show the user the capabilities in the warining dialog. bug:8633951 Change-Id: Id3442dc71dad018e606888afdc40834682fdb037
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
57bf88508e0491caced22c4c592d33aba6d88129 |
|
08-Feb-2013 |
Svetoslav <svetoslavganov@google.com> |
Refactoring of the Accessibility. 1. The accessibility manager service updates its internal state based on which settings are enabled, what accessibility services are installed and what features are requested by the enabled services. It was trying to do the minimal amount of work to react to contextual changes like these which resulted in missed cases and complex code. Now there is a single method that reads the contextual information and single method that reacts to contextual changes. This makes the code much easier to maintain. 2. The accessibility manager service was not updating its internal state when requested features from accessibility services change. It was relying on changing system settings and reacting to the settings change. This is problematic since the internal state is not updated atomically which leads to race condition bugs. For example, if touch exploration is enabled and a service requests it is disabled, the internal state will not be updated but a request for a settings change will be made. Now while the settings change is propagating another request form the same service comes to enable touch exploration but the system incorrectly thinks touch exploration is enabled. At the end the feature is disabled even though it was requested. 3. Fixed a potential NPE if the accessibility input filter's event handler was nullified between processing two event batches. 4. Fixed a bug where, if magnification is enabled, it does not work on the settings screen since the magnified bounds are not pushed from the window manager to the accessibility manager. Change-Id: Idf629a06480e12f0d88372762df6c024fe0d7856
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
901309ce5904cbc7b07b01b49ac5cd26b356998a |
|
05-Feb-2013 |
Svetoslav <svetoslavganov@google.com> |
Updating AccessibilityNodeInfo JavaDoc Change-Id: I8f80ed127c73dd4d8bcf9fe81575bb438b3d0f57
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
447d94684ee73046d769649d8247aacd581bd6e3 |
|
01-Feb-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
"Fixing backwards cmpatibility for enabling explore by touch"" This reverts commit d1ed3cea37e4156eab14b7dc8207a520c9eab700 Change-Id: I622ef034526f8f006a5a233e72487b062020e4f6
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
d1ed3cea37e4156eab14b7dc8207a520c9eab700 |
|
01-Feb-2013 |
Mike Cleron <mcleron@google.com> |
Revert "Fixing backwards cmpatibility for enabling explore by touch" This reverts commit 0a9c7c144671f70f5f1af222050bd3ec6b11fe41 Change-Id: I8da530a6d0a57163522d5a63326e787a8d22ecbf
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
0a9c7c144671f70f5f1af222050bd3ec6b11fe41 |
|
01-Feb-2013 |
Svetoslav <svetoslavganov@google.com> |
Fixing backwards cmpatibility for enabling explore by touch Change-Id: I8cbc4f03223d289547e3f3f6d1f528ad5b4f6f72
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
0ec0418c6eac5076774a74855725d9df53141907 |
|
01-Feb-2013 |
Svetoslav <svetoslavganov@google.com> |
Update the JavaDoc for the new accessibility permissions Change-Id: I1d52e848fec6c56cdb1f8ff66d07414dd2518086
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
3822896e226567c6cd3ef84518d318abd33a7624 |
|
29-Jan-2013 |
Svetoslav <svetoslavganov@google.com> |
Remove "enhance web scripts" from settings and make it requested by plug-ins. Currently we have an "enhance web accessibility" setting that has to be enabled to make sure web content is accessible. We added the setting to get user consent because we are injecting JavaScript-based screen-reader pulled from the Google infrastructure. However, many users do not know that and (as expected) do not read the user documentation, resulting in critique for lacking accessibility support in WebViews with JavaScript enabled (Browser, Gmail, etc). To smoothen the user experience now "enhance web accessibility" is a feature an accessibility plug-in can request, similarly to explore by touch. Now a user does not need to know that she has to explicitly enable the setting and web accessibility will work out-of-the-box. Before we were showing a dialog when a plug-in tries to put the device in a touch exploration mode. However, now that we have one more feature a plug-in can request, showing two dialogs (assume a plug-in wants both features) will mean that a user should potentially deal with three dialogs, one for enabling the service, and one for each feature. We could merge the dialogs but still the user has to poke two dialogs. It seems that the permission mechanism is a perfect fit for getting user permission for an app to do something, in this case to enable an accessibility feature. We need a separate permission for explore by touch and enhance web accessibility since the former changes the interaction model and the latter injects JavaScript in web pages. It is critical to get user consent for the script injection part so we need a well-documented permission rather a vague umbrella permission for poking accessibility features. To allow better grouping of the accessibility permissions this patch adds a permission group as well. bug:8089372 Change-Id: Ic125514c34f191aea0416a469e4b3481ab3200b9
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.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/accessibilityservice/AccessibilityServiceInfo.java
|
eb9862fd4c6ba1745a0f6c997e85643a4ded0643 |
|
07-Sep-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding FEEDBACK_BRAILLE to AccessibilityServiceInfo. 1. The feedback type provided by braille devices differs from all already predefined types and this change defines braille feedback type. Braille does not fit in the already predefined categories. bug:6998945 Change-Id: Ide6043bed03fdecd6d2ee45a08762f5bd07a2118
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
3ec2e1b94ab502bfa8d5e8750716108f69aa18d2 |
|
09-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Remove activation gestures form reported and add a touch explore requesting flag. 1. Delegating activation gestures has several issues that we should decide how to handle if possible before allowing an accessibility service to take over them: A) It is needed that every view than can be clicked or long pressed on reacts to such as a response to calling performClick and performLongPress which is not necessary true since the view may watch the touch events and do its own click long click detection. As a result it may be possible that there are view a user cannot interact with in touch exploration mode but can if not in that mode. B) Clicking or long pressing on a different location in a view may yield different results, for example NumberPicker. Ideally such views have to implement AccessibilityNodeProvide which provider handles correctly the request for click long press on virtual nodes. Some apps however just fire different hover accessibility events when the user is over a specific semantic portion of the view but do not provide virtual nodes. Hence, a user will not be able to interact with such semantic regions but the system can achieve that by sending the click/long click at the precise location in the view that was last touch explored. 2. Adding a flag on accessibility service info to request explore by touch mode. There is no need to put the device in this mode if node of the currently enabled accessibility services supports it. Now the problem is inverted and the service has to explicitly state its capability. 3. Fixing a bug where includeImportantViews was ignored for automation services. Change-Id: I3b29a19f24ab5e26ee29f974bbac2197614c9e2a Conflicts: api/current.txt
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.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/accessibilityservice/AccessibilityServiceInfo.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/accessibilityservice/AccessibilityServiceInfo.java
|
110414928ae13674b7ec6b816a45cf70ed521683 |
|
03-Apr-2012 |
Joe Fernandez <joefernandez@google.com> |
am c1a0e54d: am b459b619: am 945b7cb3: Merge "docs: Accessibility Dev Guide (subsumes Accessibility Best Practices)" into ics-mr1 * commit 'c1a0e54de12aee41163b84a25ea8dfc8b64304dc': docs: Accessibility Dev Guide (subsumes Accessibility Best Practices)
|
e1302edd40c5cc264f842e17e3796e0a11d6f045 |
|
06-Feb-2012 |
Joe Fernandez <joefernandez@google.com> |
docs: Accessibility Dev Guide (subsumes Accessibility Best Practices) Change-Id: Id7e3f647042d2afd390abe851be1c3b561af33ca
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
c6c25f9e28a4de73261106a80ae098347524dd2a |
|
10-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityServiceInfo does not convert correctly feedback type to string. 1. When the feedback type is set to TYPES_ALL_MASK the method feedbackTypeToString was not generating a string with all feedback types. Also the generated string sometimes could have a comma appended after the last feedback type name - this happens if the feedback type contains unknown type flag. Change-Id: I848c520cf7dae16dcd882f68275869c7ab656dd7
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
3d0edd31d8082b7b8b2cdee5efda216179f677b5 |
|
04-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityService description not internationalized. 1. AccessibilityServiceInfo loading the description string on creation and using this value. Hence, changing the locale results in reporting incorrectly localized string. Added a new loadDescription method to return the localized version. 2. Deprecated the old method. bug:5807616 Change-Id: Id82bda3c6a90fa6681b035d20da0b8688ed68da3
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
bb1b9ea8a488eec833b0be18c45dae8505876042 |
|
20-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityServiceInfo does not report properly the feedback type. Since the feedback type is an integer the bits of which correspond to a given feedback type, the AccessibilityNodeInfo#feedbackTypeToString should return a string representation of all feedback types. The current implementation incorrectly assumes that the argument had only one flag set. Note that this is a new ICS API and we would like to have this fixed. bug:5486933 Change-Id: I5e461c385e199cce4c3054907ff0acf5e9d92afc
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.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/accessibilityservice/AccessibilityServiceInfo.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/accessibilityservice/AccessibilityServiceInfo.java
|
0f55cc33f658b2793a12d609a0989348077324a4 |
|
17-Jul-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityNodeInfo does not report checkable coreclty. 1. AccessibilitiyNodeInfo's checkable property was not set. bug:5039205 Change-Id: I083d1c357c6d9875536e66e355c8a33bd580cee6
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.java
|
38e8b4e5bc3c93affdffbc064fd9db5aeccc3e8e |
|
30-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Updating accessibility documentation. Change-Id: Ice8cf9ac6918b3bfa553776c68d4619fa6559cf8
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.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/accessibilityservice/AccessibilityServiceInfo.java
|
9b31779eab896bdcc0922473b183c979cc0b874f |
|
18-Feb-2010 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix for bug 2448479
/frameworks/base/core/java/android/accessibilityservice/AccessibilityServiceInfo.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/accessibilityservice/AccessibilityServiceInfo.java
|