be2922ff34424cfb996d895cde0cb31c724d09dc |
|
28-Apr-2017 |
Phil Weaver <pweaver@google.com> |
A11y changes for API council Bug: 37749679 Bug: 37747749 Bug: 37737948 Bug: 37718183 Bug: 37720667 Bug: 37724600 Bug: 37708057 Test: Updating unit and cts tests, which still pass. Change-Id: If28bdf985c4314e8e84dcd6510f406dd4e80dd38
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
f00cd14f17c0acd6bffe78947d32ea0a2900d139 |
|
03-Mar-2017 |
Phil Weaver <pweaver@google.com> |
Basic accessibility support for picture-in-picture Exposing actions from the PIP InputConsumer to accessibility, stripping all actions from a covered PIP app, and adding the InputConsumer's actions on the PIP app's root view. We were also using an "undefined" accessibility ID to mean three different things: a root view, a host view of a virtual view hierarchy, and a truly undefined view. I've introduced new values for cases where the id could be defined. Also gathering all window IDs into one place to reduce the chance of collisions. Bug: 34773134 Test: In progress. Current cts passes. Change-Id: I97269741a292cf406272bf02359c76c396f84640
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
e231986368ea9f6e634cc1fc8d40dae0103ca8eb |
|
23-Feb-2017 |
Phil Weaver <pweaver@google.com> |
Revert "Remove abstract from AccessibilityService methods" This reverts commit 7c01afdd18fd4e81c0bfff2f9062b752a13576a5. Change-Id: I08990f4fc695b9323051e05a32c35fb9fe426146
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
7c01afdd18fd4e81c0bfff2f9062b752a13576a5 |
|
22-Feb-2017 |
Phil Weaver <pweaver@google.com> |
Remove abstract from AccessibilityService methods Two methods on AccessibilityService were declared abstract, but there doesn't seem to be a good reason for them to be abstract, as it's possible to write an accessibility service that doesn't do anything useful with the methods. Removing the abstract qualifier to reduce boilerplate for service developers. Bug: 31705365 Test: Trivial change, so I just verified that it builds. Change-Id: I2af39848c8ab343d562361fdc1c3f8ca3ecb5f00
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
7917a2f020b95a6372dd3c506183ea345ab5ae24 |
|
17-Feb-2017 |
Phil Weaver <pweaver@google.com> |
Verify fingerprint exists before using it The process will crash if we try to obtain a FingerprintManager on a device that doesn't implement one. Verify that the feature exists before trying. Bug: 34923693 Test: Ran A11y unit tests and a11y fingerprint cts. Change-Id: I48ad1c2c9c0c5739d8b1826c3c53bb817078e6cf
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
048c2bc19af4cfcb5e959f1bc07fbfa03a72e330 |
|
09-Dec-2016 |
Casey Burkhardt <caseyburkhardt@google.com> |
Initial implementation of Nav Bar Accessibility Button This allows an AccessibilityService to set a flag in its AccessibilityServiceInfo that triggers the navigation bar to show an Accessibility Button and observe callbacks when the button is clicked or there are changes in the visibility of the navigation bar. Test: Manual (Created a sample AccessibilityService) + CTS Bug:29231271 Change-Id: I03d653d85bc37df28ed71d8bba94b7c75fe56e43
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
27fcd9c97a2ceb50bab026237390207e5ee9e290 |
|
21-Jan-2017 |
Phil Weaver <pweaver@google.com> |
Accessibility can capture fingerprint gestures Bug: 27148522 Test: Unit tests for two new classes in this CL, CTS in linked CL. Change-Id: Icb5113e00b1f8724814263b3cc7f72fe4a6f0b41
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
eb1375c091d9df48b11bc44e34527b52b63d8f96 |
|
21-Dec-2016 |
Eugene Susla <eugenesusla@google.com> |
Always propagate AccessibilityCache events Bug: b/32642665 Test: Steps: - Retrieve root AccessibilityNodeInfo - Change text on its child TextView - Wait for a few seconds to let the AccessibilityEvent propagate to the AccessibilityCache - Get the child AccessibilityNodeInfo from the root, corresponding to that TextView, and ensure that it's updated to reflect the text change Change-Id: Icbdb91803b646fa06aaf11996d350f6f65c1e809
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
3cdd6c7654ff688b2dbd638e388bc56db7a020e2 |
|
03-Nov-2016 |
Phil Weaver <pweaver@google.com> |
Add check for null manger for a11y recents action Bug: 31986988 Test: Ran A11y cts Change-Id: Ia6a1e1b921d8b0008edbcf1f1a8d1d3d0eb969c6
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
752047dd3d04d35d67bfce5c938a584fbd585d49 |
|
08-Sep-2016 |
Phil Weaver <pweaver@google.com> |
Strengthen language about use of a11y API. Bug: 30898472 Change-Id: I0c2afde3f750e880cb1ef087d092719ea145756d
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
a8918f23c712e97fa1dc4911f64827d64fc906e5 |
|
05-Aug-2016 |
Phil Weaver <pweaver@google.com> |
Limit capabilities of a11y gesture dispatch. Changing the service side to accept descriptions of motion events, not motion events themselves, so we can control their creation. Bug: 30647115 Change-Id: Ia6772a1fc05df91818e3f88959d1e2b4a35fe0cc
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
2fbdd48682c32407daff4fd6577c3838c7c7a220 |
|
02-May-2016 |
Phil Weaver <pweaver@google.com> |
Reduce cost of a11y services with magnification. Services that declare that they can control magnification, but never actually make a change or register a listener waste cycles as we compute magnification data they never use. Avoid registering for magnification callbacks unless magnification gestures are enabled, a service is listening for magnification changes, or a service has changed magnification. Bug: 28425922 Change-Id: I114a833669bd53b2cd757c94ea52b65a2f838a08
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
70439244ba1abc4f32357d2ee8ff38f73158fe37 |
|
11-Mar-2016 |
Phil Weaver <pweaver@google.com> |
Fix several accessibility magnification issues. Clarifying region used for magnification as "magnificationRegion", both in the public API and in the code. There's been significant confusion about what "magnfifiedRegion" means. Removing "availableRegion" from everywhere except where it's required, as that region was identical to magnified/magnification region. Trying to shut down magnification was a complex situation where animations in progress and new magnification requests were tricky to handle correctly. It was not possible to guarantee that the magnification callbacks were unregistered consistently. There were at least two situations that led to phone restarts: 1. If a triple tap was detected between unregistering the callbacks and shutting down the input filter. In this case the magnification request would go through. 2. If an animation had just started when magnification was turned off, so the current magnification was 1.0 but the animator was about to change it. In this case the callbacks would be unregistered, and then the animator would start changing the magnification. This change makes registering and unregistering magnification atomic. It also makes MagnificationController stick around indefinitely once it is created, registering and unregistering as needed to support magnification gestures and services that control magnification. Services that merely query the status of magnification no longer register for callbacks. One part of shutting down is turning off the animation and guaranteeing that it won't try to make further changes. Adding a flag to SpecAnimationBridge and a lock in that class so we can guarantee that nothing happens when we aren't registered for magnification callbacks. Also reconfiguring all accessibility options when a service stops to make sure that only the features required by the current configuration are enabled. Bug: 27497138 Bug: 27821103 Change-Id: If697cbd34b117d82c8eee1ba7d0254089ee4241d
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
155dda1e433a003f65b1d6a65d54bec107d27db5 |
|
07-Apr-2016 |
Phil Weaver <pweaver@google.com> |
Treat accessibility gestures like physical ones. Gestures now operate on the screen as the user sees it, so they are affected by magnification. This makes gesture coordinates consistent with the node bounds in screen and makes an eye or head tracking service work much more easily. Bug: 27747314 Change-Id: Idee60398d49d8c9af7405d974893c796b034c974
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
104138198feffc8ef5069c16c210eb8684bf8662 |
|
21-Mar-2016 |
Phil Weaver <pweaver@google.com> |
Merge "Clarify docs about event recycling." into nyc-dev
|
96fea022f29f13c296ccf9388966bf0efa805f6e |
|
08-Mar-2016 |
Phil Weaver <pweaver@google.com> |
Clarify docs about event recycling. Bug: 27454838 Change-Id: I65d0ced3198dc6ad45b99e4932a0d6e32306cf10
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
4503fcfa2d26091c2a02d610da591e8b7c7b5a9f |
|
09-Mar-2016 |
Phil Weaver <pweaver@google.com> |
Update a11y gesture and magnification APIs. Making changes requested by API review. Also rethrowing all RemoveExceptions. Removing one exception thrown when a service is called before it is connected since no other method does that. Bug: 27364143 Change-Id: I9b9b549552565802da36a735fd7e3ff2e148dc34
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
3204251a4a77789d3ed64cd09fed173aca7be4bc |
|
01-Mar-2016 |
Anna Galusza <agalusza@google.com> |
Throw exception from SoftKeyboardController if connection is dead and declare SHOW_MODE_AUTO and SHOW_MODE_HIDDEN in AccessibilityService class. Bug: 27364143 Change-Id: I02c23fbfab1eae8b2a155b1d9c3857e4eb6addb1
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
315c34e7d62ce4b609f2d08b18a11a2d44e93aba |
|
20-Feb-2016 |
Phil Weaver <pweaver@google.com> |
Accessibility to toggle multiwindow mode Encapsulating the logic to toggle multiwindow mode from recents, and plumbing it through to accessibility global actions. Sending accessibility events when windows bounds change. Exposing the dock divider window type to accessibility services. Bug: 27250995 Change-Id: Ib7491f1f853dc7f01bf5c5a4ac1f914f55d0608a
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
78d2e2ddf07414eb342094ad8cf9d830b2220528 |
|
02-Feb-2016 |
Phil Weaver <pweaver@google.com> |
Clean up accessibility gestures. Closing two small holes in the implementation: 1. The gesture was dispatched before the callback was registered. It was possible for gestures that failed quickly to fail to report any status. 2. Gestures could be dispatched before the input filter was installed. Adding a wait to give the filter a chance to install before reporting a failure. Also removing an unused method on the input filter. Change-Id: I77cd80dcd2cec6c72b3761169aba5eaecf62250b (cherry picked from commit 03465fb874ccf35ead2228b66ec03afc31d7694e)
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
f3e5d1d483231d615f5e77032f787fcd8047488b |
|
29-Jan-2016 |
Anna Galusza <agalusza@google.com> |
Merge "Add API for IME control by Accessibility Services."
|
40ded287c432637158954f84a6d9cdacffc8f181 |
|
26-Jan-2016 |
Phil Weaver <pweaver@google.com> |
Clean up some accessibility documentation. Removed and updated some obsolete documentation about window content. Stated the purpose of accessibility. Updated docs for getTextSelection to include its ability to get cursor position. Clarified wording for accessibility overlays. Change-Id: Iaa11b499c2b7ece12ca182d336376d97b961b54f
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
9b278112467581e2b8d99f29cf48b9fbef9cc53f |
|
04-Jan-2016 |
Anna Galusza <agalusza@google.com> |
Add API for IME control by Accessibility Services. Change-Id: I3bb806cf420e0551a2c9ef97d95613f73e362df9
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
a9e7a3bbe859a8416e54be28bd1f055df60074e5 |
|
15-Dec-2015 |
Jinsong Mu <jinsong@google.com> |
Accessibility services can turn themselves off b/22514381 Added disableSelf() method to AccessibilityService This newly added api used used in https://googleplex-android-review.git.corp.google.com/#/c/833857/ Change-Id: I5fe60181058ef90dd496318cf270e0825bcc411a
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/AccessibilityService.java
|
14ed6cf3e7bada4932314969000d384bed6d3f92 |
|
20-Nov-2015 |
Phil Weaver <pweaver@google.com> |
Ignore feedbackType in AccessibilityEvent dispatch Send AccessibilityEvents to all accessibility services that request them. No longer refuse to send them to services with the same feedback type. Change-Id: I137905c24fc75c075ab938175ecb6ea5f39112cf
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/AccessibilityService.java
|
08c7116ab9cd04ad6dd3c04aa1017237e7f409ac |
|
28-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Remove unused imports in frameworks/base. Change-Id: I031443de83f93eb57a98863001826671b18f3b17
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
7c9746d4ef8ab3c500b501ab32933c5172a856ab |
|
20-Nov-2014 |
Alan Viverette <alanv@google.com> |
Move default token handling into WindowManagerImpl BUG: 18451795 Change-Id: I1fc6db988ad879fded5318f33d08a4f09da38907
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
d2fa5143910c74fd126359f74b08de84b0f7cf2a |
|
05-Nov-2014 |
Alan Viverette <alanv@google.com> |
Use default token instead of wrapped window manager BUG: 18248602 Change-Id: Id7f06c896dc71db3564fa21d3704222557613035
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.java
|
a4725efd0bfa52cbddf6ca587d37fc4ebcbfaf72 |
|
24-Jul-2014 |
Svetoslav <svetoslavganov@google.com> |
Improve the window query API performamce. We are caching the window data in the accessibility service process. When windows change we were sending the dalta of the windows the service knows about. To make this work when the app asked for all windows we had to call into the system as new windows may have appeared. This was slow. Now we are telling the service some windows change and if it gets the windows we cache them. We call into the system only on a cache miss and evict all windows from the cache on window change event. We do not evict the nodes of the window as the former may have just moved. If views in a window change they fire accessibility events that trigger the correct eviction. Change-Id: I586a72a2497b0d44a75288fa758e7e88817f3300
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/core/java/android/accessibilityservice/AccessibilityService.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/AccessibilityService.java
|
1e0d4af9986c8c2a658769a63bf8b385d25e0435 |
|
11-Apr-2014 |
Svetoslav <svetoslavganov@google.com> |
Adding system support for a single accessibility focus. Now that we have APIs to query all interactive windows and allow an accessibility service to put accessibility focus in each of them we have to guarantee that there is a single accessibility focus. This is required for correct operation of the touch explorer as on double tap in clicks in the center of the focused area, hence having more that one focus is an issue. Also the system is maintaining a single input focus so now accessibility focus behaves consistently with that. bug:13965563 Change-Id: I0b5c26dadfabbf80dbed8dc4602073aa575ac179
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/AccessibilityService.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/AccessibilityService.java
|
c4fccd183f1bb47a027bb303af5e65bec2f68b1b |
|
09-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
Adding APIs for an accessibility service to intercept key events. Now that we have gestures which are detected by the system and interpreted by an accessibility service, there is an inconsistent behavior between using the gestures and the keyboard. Some devices have both. Therefore, an accessibility service should be able to interpret keys in addition to gestures to provide consistent user experience. Now an accessibility service can expose shortcuts for each gestural action. This change adds APIs for an accessibility service to observe and intercept at will key events before they are dispatched to the rest of the system. The service can return true or false from its onKeyEvent to either consume the event or to let it be delivered to the rest of the system. However, the service will *not* be able to inject key events or modify the observed ones. Previous ideas of allowing the service to say it "tracks" the event so the latter is not delivered to the system until a subsequent event is either "handled" or "not handled" will not work. If the service tracks a key but no other key is pressed essentially this key is not delivered to the app and at potentially much later point this stashed event will be delivered in maybe a completely different context.The correct way of implementing shortcuts is a combination of modifier keys plus some other key/key sequence. Key events already contain information about which modifier keys are down as well as the service can track them as well. bug:8088812 Change-Id: I81ba9a7de9f19ca6662661f27fdc852323e38c00
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
bbfa585d70a6e406ccb59c17eec73ccd55e5c8e0 |
|
12-Feb-2013 |
Svetoslav <svetoslavganov@google.com> |
Adding new APIs to UiAutomation. 1. Accessibility service may set a flag to request a compressed view of the node tree representing the screen. The compressed state does not contain nodes that do to react to user actions and do not draw content, i.e. they are dumb view managers. This compressed hierarchy was very beneficial to the test team and this change is exposing the APIs. The compression has to be configurable since old tests are written against uncompressed view tree. Basically we do not hide the fact that UIAutomation is simply an accessibility service with some other useful APIs. bug:8051095 2. Accessibility service can perform global actions such as opening notifications, opening recent apps, etc. These are also needed for UI testing since there is no other way to do it via the existing UIAutomation APIs. Basically we do not hide the fact that UIAutomation is simply an accessibility service with some other useful APIs. bug:8117582 Change-Id: I7b6e24b5f7a973fdada0cc199cff9f882b10720b
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
f7e50993edfbbe4bc84e60cea84d18b935d0ad0d |
|
23-Jan-2013 |
Svetoslav <svetoslavganov@google.com> |
AccessibilityNodeINfo cache not cleared when accessibility is disabled. Change-Id: Ie674e8b2b1ece41a603bc4f39b5ce98e18c3484a
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/AccessibilityService.java
|
d44280e28884085f014806d53413ec5a68d0ac25 |
|
11-Dec-2012 |
Mita Yun <mitayun@google.com> |
resolved conflicts for merge of ebcbfb3f to master Change-Id: I0658dd4a1418fbad91d9663e5b52418a979dc683
|
ed218c706d9e91e75b94c448cee2e6150aaee57f |
|
07-Dec-2012 |
Mita Yun <mitayun@google.com> |
Use asynchronous messages for input method events. Improves the throughput of IME event handling by ensuring that input events do not get serialized behind UI traversal and drawing messages such as when the UI is animating. Added support for creating an asynchronous Handler as part of a HandlerCaller. It turns out we should be using an asynchronous Handler not only in IME dispatch but also in accessibility and wallpaper events where HandlerCaller is used. So fixed those services to also use an asynchronous Handler. Change-Id: I0b19140c9d5ca6ee300c1a150c48312fd55ed8eb
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
152e9bb81aa5b2ab4637f4b2dae04b3ce89fa891 |
|
13-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Refactoring of the screen magnification feature. 1. The screen magnification feature was implemented entirely as a part of the accessibility manager. To achieve that the window manager had to implement a bunch of hooks for an external client to observe its internal state. This was problematic since it dilutes the window manager interface and allows code that is deeply coupled with the window manager to reside outside of it. Also the observer callbacks were IPCs which cannot be called with the window manager's lock held. To avoid that the window manager had to post messages requesting notification of interested parties which makes the code consuming the callbacks to run asynchronously of the window manager. This causes timing issues and adds unnecessary complexity. Now the magnification logic is split in two halves. The first half that is responsible to track the magnified portion of the screen and serve as a policy which windows can be magnified and it is a part of the window manager. This part exposes higher level APIs allowing interested parties with the right permissions to control the magnification of a given display. The APIs also allow a client to be registered for callbacks on interesting changes such as resize of the magnified region, etc. This part servers as a mediator between magnification controllers and the window manager. The second half is a controller that is responsible to drive the magnification state based on touch interactions. It also presents a highlight when magnified to suggest the magnified potion of the screen. The controller is responsible for auto zooming out in case the user context changes - rotation, new actitivity. The controller also auto pans if a dialog appears and it does not interesect the magnified frame. bug:7410464 2. By design screen magnification and touch exploration work separately and together. If magnification is enabled the user sees a larger version of the widgets and a sub section of the screen content. Accessibility services use the introspection APIs to "see" what is on the screen so they can speak it, navigate to the next item in response to a gesture, etc. Hence, the information returned to accessibility services has to reflect what a sighted user would see on the screen. Therefore, if the screen is magnified we need to adjust the bounds and position of the infos describing views in a magnified window such that the info bounds are equivalent to what the user sees. To improve performance we keep accessibility node info caches in the client process. However, when magnification state changes we have to clear these caches since the bounds of the cached infos no longer reflect the screen content which just got smaller or larger. This patch propagates not only the window scale as before but also the X/Y pan and the bounds of the magnified portion of the screen to the introspected app. This information is used to adjust the bounds of the node infos coming from this window such that the reported bounds are the same as the user sees not as the app thinks they are. Note that if magnification is enabled we zoom the content and pan it along the X and Y axis. Also recomputed is the isVisibleToUser property of the reported info since in a magnified state the user sees a subset of the window content and the views not in the magnified viewport should be reported as not visible to the user. bug:7344059 Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
e20a177d3f147f3011647c3bdab401f90b2c5d1d |
|
26-Sep-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding a global accessibility action to open quick settings. 1. Added APIs for opening the quick settings to the StatusBarManagerService and the local StatausBarManager. The new APIs are protected by the old EXPAND_STATUS_BAR permission. Renamed the expand* and collapse* non-public APIs that are expanding the notifications to expandNotifications* collapseNotifications* to better convey what they do given that this change adds expandQuickSettings* and collapseQuickSettings*. Added a global action to the accessibility layer to expand the quick settings which is calling into the new status bar manager APIs. bug:7030487 Change-Id: Ic7b46e1a132f1c0d71355f18e7c5a9a2424171c3
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
53b0fda5fd7c532fc1d93abd5f8a85276821cc6d |
|
06-Aug-2012 |
Scott Main <smain@google.com> |
misc doc bugs. Fix sdk samples path Fix method signature in fragment doc code snippet Fix typo in a11y javadoc code snippet Fix markup error in brands page Fix markup error on content providers doc Fix typo on about>start page Change-Id: Ie2a528dd4fbd19e5cb1c0844f6fc6272669c8ab9
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
636fd528f7ad51f565a390226d9f469f8c675ccf |
|
06-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Docs (mostly): enumerate JELLY_BEAN target SDK changes. Okay this isn't entirely docs. I have un-hidden the new permission for binding to accessibility services; we were going to go out with it hidden since it didn't go into factory ROM, but now that we are doing other things we might as well expose it. Also changed a log from E to W, since it is not an error. Change-Id: I9226c95e3b63e12218fe41dc3f4290d9824a9e5c
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
1e7456ba74f93cdf80dc430aa082cc3c271b30b1 |
|
17-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing the build for real. Change-Id: I792d029c7fff4d96fbe238ff4b3f268cb8603b95
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
53e184d34e7c5b1a65c74fac55f9a635d8131dda |
|
17-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility service needs to request permission to be bound to. 1. Every accessibility services targeting JellyBean or higher has to request a special permission for the system to bind to it. Change-Id: I6e579326bdf3597f148d6c67317455701ec8af68
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
7b1e0c7046abefc0b40884b36197c8a803d9cf6d |
|
13-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Removing default accessibility gesture handling. 1. The initial design was to have some accessibility gestures being handled by the system if the gesture handling access service does not consume the gesture. However, we are not sure what a good default is and once we add a default handler we cannot remove it since people may rely on it. Thus, we take the simples approach and let the accessibility service handle the gestures. If no gestures are handled the system will work in explore by touch as before. bug:5932640 Change-Id: I865a83549fa03b0141d27ce9713e9b7bb45a57b4
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
e4abc512aa6474f0106f407f7b399832da34483f |
|
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
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
87bd0dccf7f2558ea1a5e0fce523aea022709834 |
|
08-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Renaming the constants for activation and long press. 1. We will have a double tap to activate an item and tap and hold to perform a long press. Change-Id: Ibd9d8774e5a4693d8868d1128e55a82ff0c3a80b
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
65d98ad5b3f2e5ec03f14cb0538c572a427ae1a8 |
|
03-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Remove accessibility gestures for clockwise and counter clock wise circle. 1. The clockwise and counter clockwise circle gestures are difficult to perform for a blind user. Some user studies have shown that so nuke them. bug:6435260 Change-Id: I81d23bd3c450239fe17b4b8c60bafab00daa480a
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/AccessibilityService.java
|
0846e29d0b5640cfad4496c8484fb9aaa2ba4ccf |
|
19-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding API for getting the root node info in the active window. 1. This APIs is useful for accessibility services since very often they want to get access to the root node in the current window to determine where accessibility focus is and subsequently find a next view to take accessibility focus. Change-Id: Ide5231f832d9ce2e9b14dc411dfd675f753a4edb
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
005b83b0c62d3d0538f0d566b08bd457015ec661 |
|
17-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding some more gestures and actions for accessibility. 1. Added more gesture for accessibility. After a meeting with the access-eng team we have decided that the current set of gestures may be smaller than needed considering that we will use four gestures for home, back, recents, and notifications. 2. Adding actions for going back, home, opening the recents, and opening the notifications. 3. Added preliminary mapping from some of the new gestures to the new actions. 4. Fixed a bug in the accessibility interaction controller which was trying to create a handled on the main looper thread which may be null if the queried UI is in the system process. Now the context looper of the root view is used. 5. Fixed a bug of using an incorrect constant. 6. Added a missing locking in a couple of places. 7. Fixed view comparison for accessibilityt since it was not anisymmetric. bug:5932640 bug:5605641 Change-Id: Icc983bf4eafefa42b65920b3782ed8a25518e94f
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/AccessibilityService.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/AccessibilityService.java
|
f76a50ce8fdc6aea22cabc77b2977a1a15a79630 |
|
09-Mar-2012 |
Ken Wakasa <kwakasa@google.com> |
Fix obvious typos under frameworks/base/core Change-Id: Ia5fc3db1bb51824e7523885553be926bcc42d736
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
79311c4af8b54d3cd47ab37a120c648bfc990511 |
|
18-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Speedup the accessibility window querying APIs and clean up. 1. Now when an interrogating client requires an AccessibilibtyNodeInfo we aggressively prefetch all the predecessors of that node and its descendants. The number of fetched nodes in one call is limited to keep the APIs responsive. The prefetched nodes infos are cached in the client process. The node info cache is invalidated partially or completely based on the fired accessibility events. For example, TYPE_WINDOW_STATE_CHANGED event clears the cache while TYPE_VIEW_FOCUSED removed the focused node from the cache, etc. Note that the cache is only for the currently active window. The ViewRootImple also keeps track of only the ids of the node infos it has sent to each querying process to avoid duplicating work. Usually only one process will query the screen content but we support the general case. Also all the caches are automatically invalidated so not additional bookkeeping is required. This simple strategy leads to 10X improving the speed of the querying APIs. 2. The Monkey and UI test automation framework were registering a raw event listener for accessibility events and hence perform connection and cache management in similar way to an AccessibilityService. This is fragile and requires the implementer to know internal framework stuff. Now the functionality required by the Monkey and the UI automation is encapsulated in a new UiTestAutomationBridge class. To enable this was requited some refactoring of AccessibilityService. 3. Removed the *doSomethiong*InActiveWindow methods from the AccessibilityInteractionClient and the AccessibilityInteractionConnection. The function of these methods is implemented by the not *InActiveWindow version while passing appropriate constants. 4. Updated the internal window Querying tests to use the new UiTestAutomationBridge. 5. If the ViewRootImple was not initialized the querying APIs of the IAccessibilityInteractionConnection implementation were returning immediately without calling the callback with null. This was causing the client side to wait until it times out. Now the client is notified as soon as the call fails. 6. Added a check to guarantee that Views with AccessibilityNodeProvider do not have children. bug:5879530 Change-Id: I3ee43718748fec6e570992c7073c8f6f1fc269b3
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
d116d7c78a9c53f30a73bf273bd7618312cf3847 |
|
22-Nov-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing memory leaks in the accessiiblity layer. 1. AccessibilityInteractionConnections were removed from the AccessiiblityManagerService but their DeathRecipents were not unregistered, thus every removed interaction connection was essentially leaking. Such connection is registered in the system for every ViewRootImpl when accessiiblity is enabled and inregistered when disabled. 2. Every AccessibilityEvent and AccessiilbityEventInfo obtained from a widnow content querying accessibility service had a handle to a binder proxy over which to make queries. Hoewever, holding a proxy to a remote binder prevents the latter from being garbage collected. Therefore, now the events and infos have a connection id insteand and the hindden singleton AccessiiblityInteaction client via which queries are made has a registry with the connections. This class looks up the connection given its id before making an IPC. Now the connection is stored in one place and when an accessibility service is disconnected the system sets the connection to null so the binder object in the system process can be GCed. Note that before this change a bad implemented accessibility service could cache events or infos causing a leak in the system process. This should never happen. 3. SparseArray was not clearing the reference to the last moved element while garbage collecting thus causing a leak. bug:5664337 Change-Id: Id397f614b026d43bd7b57bb7f8186bca5cdfcff9
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/accessibilityservice/AccessibilityService.java
|
4e2a762eae1f6981d32e6098a95498865ad7f795 |
|
27-Jul-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Not user generated accessibility events can change the interrogation allowing window. 1. Events not generated by the user can change the interrogation allowing window unpredicatably. For example when a ListView lays out its children it fires an accessibility events and changes the currently active window while the user interaction may be happening in another window say a dialog. Now the interrogation allowing window is changed when a new window is shown or the user has touch explored it. bug:5074116 Change-Id: I8dde12bbec807d32445a781eedced9b95312b3e2
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
38e8b4e5bc3c93affdffbc064fd9db5aeccc3e8e |
|
30-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Updating accessibility documentation. Change-Id: Ice8cf9ac6918b3bfa553776c68d4619fa6559cf8
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
eeee4d2c01d3c4ed99e4891dbc75c7de69a803fa |
|
11-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Final polish of the interrogation feature. 1. Added a new event type for notifying client accessibilitiy services for changes in the layout. The event is fired at most once for a given time frame and is delivered to clients only if it originates from the window that can be interrogated. 2. Exposed the findByText functionality in AccessibilityNodeInfo. This is very useful for an accessibility service since it allows searching for something the user knows is on the screen thus avoiding touch exploring the content. Touch exploring is excellent for learning the apps but knowing them search is much faster. 3. Fixed a bug causing an accessibiliby service not to receive the event source in case of more than one service is registered and one of them does not have paermission to interrogate the window. The same event was dispatched to multiple services but if one of them does not have interrogation permission the event is modified to remove the source causing subsequent serivices not to get the later. 4. Moved the getSource setSource methods to AccessibilityRecord instead in AccessibilityEvent. 5. Hiden some protected members in AccessibilityRecod which should not be made public since getters exist. 6. Added the View absolute coordinates in the screen to AccessibilityNodeInfo. This is needed for fast computation of relative positions of views from accessibility - common use case for the later. 7. Fixed a couple of marshalling bugs. 8. Added a test for the object contract of AccessibilityNodeInfo. Change-Id: Id9dc50c33aff441e4c93d25ea316c9bbc4bd7a35
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/accessibilityservice/AccessibilityService.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/AccessibilityService.java
|
7ed6ee5692c808cf0ebb3ee208fc8ee1314622c2 |
|
11-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #1983406: Soft keyboard doesn't show up in an EditText with "digits" attribute set Also pretend to fix #2054990 (com.android.frameworktest: java.lang.NullPointerException at android.accessibilityservice.AccessibilityService$IEventListenerWrapper.executeMessage( AccessibilityService.java:215))... simply by making the variable that apparently was null final, to assure myself that there is no possible way in the world for it to be null. :p Change-Id: I73e337d65b8360721896a0296691257b3e47564b
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
85f6fb713feb258197f17a86c45874d542194b71 |
|
28-Aug-2009 |
Charles Chen <clchen@google.com> |
Fixing bug 2086021. AccessiblityService could sometimes get a null pointer exception if multiple accessibility services are running and there are several events all happening within a short period of time.
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.java
|
7f2054392e9957d3ba8579ef08c29cfb27df564e |
|
28-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Updates from API review. * AccessibilityService -- document onBind() to not be implemented. * GestureLibrary.getLearner() -- needs to be hidden. * IntentSender -- remove protected constructors, document that it is retrieved from a PendingIntent. * Hide permissions: SHUTDOWN, STOP_APP_SWITCHES. * Context -- hide BACKUP_SERVICE. * ContextWrapper -- hide getSharedPrefs bla h blah * Intent.parseUri() -- fix docs. * ApplicationInfo.FLAG_TEST_ONLY?!? * Hide MockContext.getSharedPrefs blah blah
/frameworks/base/core/java/android/accessibilityservice/AccessibilityService.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/AccessibilityService.java
|