af43110c020a9557233a64c08cede07bb37fe440 |
|
04-Oct-2013 |
Alan Viverette <alanv@google.com> |
Provide example actions in AccessibilityEvent.setAction() docs BUG: 11070461 Change-Id: I05799e721dd1285e5165e94c7d63084010fa478b
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
77e9a28e2faa36f127231b842476d47f9823a83a |
|
13-Sep-2013 |
Alan Viverette <alanv@google.com> |
Add live region politeness to View, AccessibilityNodeInfo Alters the content change API to contain a bit mask of types of changes represented by the event. Live regions send CONTENT_CHANGED events immediately. Removes unused APIs for EXPANDABLE/EXPANDED. BUG: 10527284 Change-Id: I21523e85e47df23706976dc0a8bf615f83072c04
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
6254f4806dd3db53b7380e77fbb183065685573e |
|
05-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Optimizing AccessibilityNodeInfo caching. 1. Before we were firing an accessibility event from the common predecessor of views with accessibility related state changes every X amount of time. These events designate that the tree rooted at the source is invalid and should not be cached. However, some of the state changes do not affect the view tree structure and we can just refresh the node instead of evicting and recaching nodes infos for views that did not change. Hence, we need a way to distinguish between a subtree changed over a node changed. Adding a new event type will not work since if say two siblings have local changes and their predecessor fires a window state change event, the client will drop the subtree rooted at the parent including the two views with changes. Subsequent, more specialized events emitted from the two changed siblings will be useless since the parent which did not changed is already evicted from the cache. Conversely, if the specialized events are fired from the two siblings with local changes and they are refreshed in the cache the subsequent window state change event from the common predecessor will force the refreshed nodes to be evicted. Hence, to enable distinction between node being changed and a subtree baing changed while not changing existing behavior, we will fire only window content change event with an additional argument specifying what changed - node or a subtree for now. Also if the changes are local to a view we fire the window content changed event from the view. So, the two siblings will fire such an event independently and the client will know that these are local changes and can just refresh the node. If the changes are structural, then we fire the window state change event from the common predecessor. 2. Added the input type of a text view as one of the properties reported by an AccessibilityNodeInfo. It is nice to prompt the user what input is expected. 3. Added a bundle for optional information to AccessiiblityNodeInfo. For example, it will be used for putting web specific properties that do not map cleanly to Android specific ones in WebView. 4. AccessibilityInteractionController was not taking into account whether the current accessibility focused node is shown before returing it. Hence, a disconnected node would be returned and caching it puts our cahche in an inconsistent state. Change-Id: I8ed19cfb4a70bdd7597c3f105487f1651cffd9e0
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
abad55d860be793b8b9b3e288a74214da89fb368 |
|
08-May-2013 |
Svetoslav <svetoslavganov@google.com> |
Fixing the accessibility text traversal in extend mode. We added APIs to allow an accessibility service to extend the selection while moving the cursor at a given granularity such as word, character, etc. The problem is that the traversal was extending only the end of the selection while moving forward and the start of the selection while moving backward. This leads to a case in which the user cannot shrink/extend the selection because for example instead of shrinking the end of the selection the implementation was extending the start. Now extending the selection moves only the selection end. This is the same behavior as text view using a keyboard. Tests: https://googleplex-android-review.googlesource.com/#/c/307062 bug:8839844 Change-Id: Id6965b102647df909f61301fcc8ec05458dd5881
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
f4782ec9c57a40224ac0974fce6b6fe280c829ce |
|
28-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Switching the accessibility poolable classes to the new pool management APIs. The pool management APIs were simplified and using them requires much less code than implementing your own pooling. Using common pooling logic is also less error prone. This change swithces AccessibilityEvent and AccessibilityNodeInfo to the new APIs. Change-Id: I2dcfe2e1b0b0be5f89bd92359766ae3d6f8a143b
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
6ce77cdd6aff7193c746cd1eb87d5babf9158bac |
|
22-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding dump support for the accessibility manager service. Change-Id: Ibc8d9eac3be065f1a753e1401568b8f93263b051
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
77276b60851a158ad3e142cb3b091d57ae5ceffb |
|
14-Sep-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding accessibility events for touch and gesture detection states. 1. Currently the system fires accessibility events to announce the start and end of a touch exploration gesture. However, such a gesture starts after we have decided that the user is not performing a gesture which is achieved by measuring speed of movement during a threshold distance. This allows an accessibility service to provide some feedback to the user so he knows that he is touch exploring. This change adds event types for the first and last touches of the user. Note that the first touch does not conincide with the start of a touch exploration gesture since we need a time or distance to pass before we know whether the user explores or gestures. However, it is very useful for an accessibility service to know when the user starts to interact with the touch screen so it can turn the speech off, to name one compelling use case. This change also provides event types for the start and end of gesture detection. If the user has moved over the threshold with a speed greater than X, then the system detects gestures. It is useful for an accessibility service to know the begin and end of gesture detection so it can provide given feedback type for such a gesture, say it may produce haptic feedback or sound that differs for the one for touch exploration. The main benefit of announcing these new events is that an accessibility service can provide feedback for each touch state allowing the user to always know what he is doing. bug:7166935 Change-Id: I26270d774cc059cb921d6a4254bc0aab0530c1dd
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
6d17a936f73976971135aa1e6248662533343292 |
|
28-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Text traversal at various granularities. 1. Implementing text content navigation at various granularities. For views that have content description but no text the content description is the traversed at character and word granularities. For views that inherit from TextView the supported granularities are character, word, line, and page. bug:5932640 Conflicts: core/java/android/view/View.java Conflicts: core/java/android/view/View.java Change-Id: I66d1e16ce9ac5d6b49f036b17c087b2a7075e4c0
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
2b435aada3d274a9c08d334946fff1ab9ba15b48 |
|
05-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
API REVIEW: android.view.accessibility 1. Changed all references to granularity to movement granularity. BTW, to be more precise it should be text movement granularity. bug:6435232 Change-Id: If6366b002ca3390f74918995b342baff2cbcfd01
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
b7ff3255c6d4e12f9d2334e3bbec0a125b7b09dc |
|
25-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding explicit text traversal granularities and actions for web navigation. 1. The granularities for traversing the text content of an accessibility node info are now predefined constants and custom ones will not be supported. This is the simplest solution - we can always add namespaced user defined ones (unlikely). 2. Added actions for traversing web content. These actions can be used by an accessibility service to transparently drive the JavaScript based screen reader that is used for handling web content. 3. Added a new accessibility event type for traversing the content of a view. This event is needed to announce to the user what is the next element, i.e. the one next to the cursor, after the view's text was traversed. bug:5932640 bug:6389591 Change-Id: I144647da55bc4005c64f89865ef333af8359e145
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
4213804541a8b05cd0587b138a2fd9a3b7fd9350 |
|
20-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus - framework Usefulness: Keep track of the current user location in the screen when traversing the it. Enabling structural and directional navigation over all elements on the screen. This enables blind users that know the application layout to efficiently locate desired elements as opposed to try touch exploring the region where the the element should be - very tedious. Rationale: There are two ways to implement accessibility focus One is to let accessibility services keep track of it since they have access to the screen content, and another to let the view hierarchy keep track of it. While the first approach would require almost no work on our part it poses several challenges which make it a sub-optimal choice. Having the accessibility focus in the accessibility service would require that service to scrape the window content every time it changes to sync the view tree state and the accessibility focus location. Pretty much the service will have to keep an off screen model of the screen content. This could be quite challenging to get right and would incur performance cost for the multiple IPCs to repeatedly fetch the screen content. Further, keeping virtual accessibility focus (i.e. in the service) would require sync of the input and accessibility focus. This could be challenging to implement right as well. Also, having an unlimited number of accessibility services we cannot guarantee that they will have a proper implementation, if any, to allow users to perform structural navigation of the screen content. Assuming two accessibility services implement structural navigation via accessibility focus, there is not guarantee that they will behave similarly by default, i.e. provide some standard way to navigate the screen content. Also feedback from experienced accessibility researchers, specifically T.V Raman, provides evidence that having virtual accessibility focus creates many issues and it is very hard to get right. Therefore, keeping accessibility focus in the system will avoid keeping an off-screen model in accessibility services, it will always be in sync with the state of the view hierarchy and the input focus. Also this will allow having a default behavior for traversing the screen via this accessibility focus that is consistent in all accessibility services. We provide accessibility services with APIs to override this behavior but all of them will perform screen traversal in a consistent way by default. Behavior: If accessibility is enabled the accessibility focus is the leading one and the input follows it. Putting accessibility focus on a view moves the input focus there. Clearing the accessibility focus of a view, clears the input focus of this view. If accessibility focus is on a view that cannot take input focus, then no other view should have input focus. In accessibility mode we initially give accessibility focus to the topmost view and no view has input focus. This ensures consistent behavior accross all apps. Note that accessibility focus can move hierarchically in the view tree and having it at the root is better than putting it where the input focus would be - at the first input focusable which could be at an arbitrary depth in the view tree. By default not all views are reported for accessibility, only the important ones. A view may be explicitly labeled as important or not for accessibility, or the system determines which one is such - default. Important views for accessibility are all views that are not dumb layout managers used only to arrange their chidren. Since the same content arrangement can be obtained via different combintation of layout managers, such managers cannot be used to reliably determine the application structure. For example, a user should see a list as a list view with several list items and each list item as a text view and a button as opposed to seeing all the layout managers used to arrange the list item's content. By default only important for accessibility views are regared for accessibility purposes. View not regarded for accessibility neither fire accessibility events, nor are reported being on the screen. An accessibility service may request the system to regard all views. If the target SDK of an accessibility services is less than JellyBean, then all views are regarded for accessibility. Note that an accessibility service that requires all view to be ragarded for accessibility may put accessibility focus on any view. Hence, it may implement any navigational paradigm if desired. Especially considering the fact that the system is detecting some standard gestures and delegates their processing to an accessibility service. The default implementation of an accessibility services performs the defualt navigation. bug:5932640 bug:5605641 Change-Id: Ieac461d480579d706a847b9325720cb254736ebe
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/view/accessibility/AccessibilityEvent.java
|
51ab90cab1609cf0ddd2dfe5a660f020d823d4d5 |
|
09-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding an announcement type accessibility event and a method on View to announce. 1. The need for sending an accessibility event to announce a context change which does not cleanly fit into the existing UI transition UI events has come quite a few time in application development. To avoid retrofitting accessibility event types that do not semantically match the intent to just announce a short message this patch is adding specialized event type. Also a helper method on View is added to sheild developers from knowing how to construct and send such an event. bug:5977979 Change-Id: Iaf5f620426f8616be67fbf243a02ad5b606c949b
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
f3b4f3163b5b4c0a54a2643f07c97c47b14a1eb7 |
|
01-Dec-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
resolved conflicts for merge of 26f7a81f to master Change-Id: I6bf5fd7c0de7945cef84602dbe3a7bbed587700f
|
d116d7c78a9c53f30a73bf273bd7618312cf3847 |
|
22-Nov-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing memory leaks in the accessiiblity layer. 1. AccessibilityInteractionConnections were removed from the AccessiiblityManagerService but their DeathRecipents were not unregistered, thus every removed interaction connection was essentially leaking. Such connection is registered in the system for every ViewRootImpl when accessiiblity is enabled and inregistered when disabled. 2. Every AccessibilityEvent and AccessiilbityEventInfo obtained from a widnow content querying accessibility service had a handle to a binder proxy over which to make queries. Hoewever, holding a proxy to a remote binder prevents the latter from being garbage collected. Therefore, now the events and infos have a connection id insteand and the hindden singleton AccessiiblityInteaction client via which queries are made has a registry with the connections. This class looks up the connection given its id before making an IPC. Now the connection is stored in one place and when an accessibility service is disconnected the system sets the connection to null so the binder object in the system process can be GCed. Note that before this change a bad implemented accessibility service could cache events or infos causing a leak in the system process. This should never happen. 3. SparseArray was not clearing the reference to the last moved element while garbage collecting thus causing a leak. bug:5664337 Change-Id: Id397f614b026d43bd7b57bb7f8186bca5cdfcff9
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
e9dc7c9f031b494c6ebe156de957f0a8f2cd58b0 |
|
19-Nov-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
am bdc2912d: am d8a3cabc: Merge "Text selection AccessibilityEvents are missing text." into ics-mr1 * commit 'bdc2912da64e5e6402c73997d637224d905ae825': Text selection AccessibilityEvents are missing text.
|
84dd52e394d27b5cdf638132808e2585a9049480 |
|
18-Nov-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Text selection AccessibilityEvents are missing text. The text selection change event was not added to the text populating accessibility events in View. bug:5638709 Change-Id: Ie7e319bc07d7e6c48f178a6c1bd22b1fe32ff515
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
021078554b902179442a345a9d080a165c3b5139 |
|
04-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding APIs to enable reporting virtual view hierarchies to accessibility serivces. Added an interface that is the contract for a client to expose a virtual view hierarchy to accessibility services. Clients impement this interface and set it in the View that is the root of the virtual sub-tree. Adding this finctionality via compostion as opposed to inheritance enables apps to maintain backwards compatibility by setting the accessibility virtual hierarchy provider on the View only if the API version is high enough. bug:5382859 Change-Id: I7e3927b71a5517943c6cb071be2e87fba23132bf
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
9920f4fdeaa3a4c597f62c3d082becc48ea8a7ab |
|
08-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility text changed event text not populated. Added the TYPE_VIEW_TEXT_CHANGED event to the populating events. bug:5430831 Change-Id: I78e87640ea4279227d89f399ad43e9b88eb4a486
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
d9ee72fddb8be40e414a831fb80458dc48699613 |
|
06-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing errors in position information of scrollable views reported for accessibility. 1. ScrollView/HorizontalScroll view were reporting only the scroll X and Y but failed to convey the max scroll along X and Y so the position can be determined. 2. WebView was not reporting correctly its scroll position for accessibility. 3. Some descendants of AdapterView were reporting incorrect position information. 4. Updated the accessibility docs with some details about the scroll information. 5. Cleaned up duplicated code. bug:5412132 bug:5412265 Change-Id: I165e73ecde027dad811425b9f395a3f758c923ba
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
82e236d72ac197d6673d0b4d484fe5f0b9436731 |
|
30-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
The logic for not populating text to some accessibility events is scattered. 1. Some accessibility evenents should not and were not dispatched for text population but there was no centralized location for enforcing this - rather the system was firing them in a specific way or there were conditions in a few places enforcing that. Now this is centralized and clean. 2. Updated the documentation with some new event types the were lacking. 3. Explicitly stated in the documentaition which events are dispatched to the sub-tree of the source for text populatation. bug:5394527 Change-Id: I86e383807d777019ac98b970c7d9d02a2f7afac6
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
e4aa13b20166219a62916a92294055e7cc5c9f10 |
|
01-Aug-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityEvent#toString() always reports -1 for record count. 1. The implementation of toString() was calling a wrong method for the record count. bug:5087078 Change-Id: I4ca79faa6ccce135eb6fe797de7b08e30f8b3e71
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
35bfedeaba724aeadc6f6c890269cb6bf7ef42f5 |
|
15-Jul-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration separate setting and API to poll the latter state. 1. Seperated touch exploration to be a seperate setting rather being magically enabled by the system of accessiiblity is on the there is at leas one accessibility service that speaks enabled. Now there is a setting for requesting touch exploration but still the system will enabled it only if that makes sense i.e. accessibility is on and one accessibility service that speaks is enabled. 2. Added public API for checking of touch exploration is enabled. 3. Added description attribute in accessibility service declaration which will be shown to the user before enabling the service. 4. Added API for quick cloning of AccessibilityNodeInfo. 5. Added clone functionality to SparseArray, SparseIntArray, and SparseBooleanArray. bug:5034010 bug:5033928 Change-Id: Ia442edbe55c20309244061cd9d24e0545c01b54f
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
38e8b4e5bc3c93affdffbc064fd9db5aeccc3e8e |
|
30-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Updating accessibility documentation. Change-Id: Ice8cf9ac6918b3bfa553776c68d4619fa6559cf8
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
a20cdc06e599c6fef784a0a479e8329f95e4bd09 |
|
27-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing the build Change-Id: Ic3664e5cd812d5fe59c9cf2657a441ca76a61135
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
a0156177cdc809795dd8bc5a19943dd2b6f82b66 |
|
27-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Added scroll and text selection change accessibility events. 1. Added scrolling accessibility event to provicde feedback when a view is scrolled. Note: We need scroll events for ICS since even though we have touch exploration the user does not know when something is scrollable and not feedback is provided while scrolling. bug:4902097 2. Added a text selection change event to provide feedback for selection changes including cursor movement. Note: We need the text selection change events for ICS since even though the IME supports navigation in text fields the user receives no feedback for the current selection/ cursor position. bug:4586186 3. Added a scrollable property to both AccessibilityEvent and AccessibilityNodeInfo. The info has to describe the source in terms of all properties that make sense for accessibility purposes and the event has this property (kinda duplicated) since clients will aways want to know if the source is scrollable to provided clue to the user and we want to avoid pulling the info of the source for every accessibility event. Change-Id: I232d6825da78e6a12d52125f51320217e6fadb11
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
34e350daf89aed09ac748c2185f4506772a63b3f |
|
21-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
ListView do not fire accessibility hover events. 1. AccessibilityEvent was incorrectly setting the connection of an owned AccessibilityRecord after the record is initialized since during initialization the record may become sealed. bug:4724101 Change-Id: I39087dc8023c62252f31431ece23de901dc45972
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.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/view/accessibility/AccessibilityEvent.java
|
9210ccbdc3629cead65a822d729e1783a773118c |
|
09-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityNodeInfo and AccessibilityEvent to initialized properly. Change-Id: Id3a1b33a222790214820af4a8b49378f08e53558
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
8643aa0179e598e78d938c59035389054535a229 |
|
20-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Interrogation of the view hierarchy from an AccessibilityService. 1. Views are represented as AccessibilityNodeInfos to AccessibilityServices. 2. An accessibility service receives AccessibilityEvents and can ask for its source and gets an AccessibilityNodeInfo which can be used to get its parent and children infos and so on. 3. AccessibilityNodeInfo contains some attributes and actions that can be performed on the source. 4. AccessibilityService can request the system to preform an action on the source of an AccessibilityNodeInfo. 5. ViewAncestor provides an interaction connection to the AccessibiltyManagerService and an accessibility service uses its connection to the latter to interact with screen content. 6. AccessibilityService can interact ONLY with the focused window and all calls are routed through the AccessibilityManagerService which imposes security. 7. Hidden APIs on AccessibilityService can find AccessibilityNodeInfos based on some criteria. These API go through the AccessibilityManagerServcie for security check. 8. Some actions are hidden and are exposes only to eng builds for UI testing. Change-Id: Ie34fa4219f350eb3f4f6f9f45b24f709bd98783c
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
cc4053e031371456fe54d51bbad1db721db4ae38 |
|
23-May-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility serviceconfiguration via meta-data Note: This is a part of two CL change and contains the system changes without updates to the settings. 1. Added a mechanism for configuring an accessibility service via XML file specified in a meta-data tag (similar to IMEs). 2. Added property for specifying a settings activity for an accessibility service. 3. Refactored the APIs in AccessibilityManager to return lists of AccessiblityServiceInfo instead ServiceInfo since the former describes an AccessibilityService in particular (similar to IMEs). Change-Id: Ie8781bb7e0cdb329e583b6702a612a507367ad7b
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
887e1a17eb9b12448f5929791b564565b2665aab |
|
30-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration - nits Change-Id: Ie49558e0a81218dbad70c02f81dd7a59b3213d5c
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
736c2756bf3c14ae9fef7255c119057f7a2be1ed |
|
23-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration feature, event bubling, refactor 1. Added an Input Filter that interprets the touch screen motion events to perfrom accessibility exploration. One finger explores. Tapping within a given time and distance slop on the last exlopred location does click and long press, respectively. Two fingers close and in the same diretion drag. Multiple finglers or two fingers in different directions or two fingers too far away are delegated to the view hierarchy. Non moving fingers "accidentally grabbed the device for the scrren" are ignored. 2. Added accessibility events for hover enter, hover exit, touch exoloration gesture start, and end. Accessibility hover events are fired by the hover pipeline. An accessibility event is dispatched up the view tree and the topmost view fires it. Thus predecessors can augment the fired event. An accessibility event has several records and a predecessor can optionally modify, delete, and add such to the event. 3. Added onPopulateAccessibilityEvent and refactored the existing accessibility code to use it. 4. Added API for querying the currently enabled accessibility services by feedback type. Change-Id: Iea2258c07ffae9491071825d966dc453b07e5134
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
3fb3d7c4e756bd32d5abde0abca9ab52d559bc84 |
|
23-Apr-2011 |
Adam Powell <adamp@google.com> |
Revert "Touch exploration feature, event bubling, refactor" This reverts commit ac84d3ba81f08036308b17e1ab919e43987a3df5. There seems to be a problem with this API change. Reverting for now to fix the build. Change-Id: Ifa7426b080651b59afbcec2d3ede09a3ec49644c
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
ac84d3ba81f08036308b17e1ab919e43987a3df5 |
|
05-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration feature, event bubling, refactor 1. Added an Input Filter that interprets the touch screen motion events to perfrom accessibility exploration. One finger explores. Tapping within a given time and distance slop on the last exlopred location does click and long press, respectively. Two fingers close and in the same diretion drag. Multiple finglers or two fingers in different directions or two fingers too far away are delegated to the view hierarchy. Non moving fingers "accidentally grabbed the device for the scrren" are ignored. 2. Added accessibility events for hover enter, hover exit, touch exoloration gesture start, and end. Accessibility hover events are fired by the hover pipeline. An accessibility event is dispatched up the view tree and the topmost view fires it. Thus predecessors can augment the fired event. An accessibility event has several records and a predecessor can optionally modify, delete, and add such to the event. 3. Added onPopulateAccessibilityEvent and refactored the existing accessibility code to use it. 4. Added API for querying the currently enabled accessibility services by feedback type. Change-Id: Iec03c6c3fe298de3f14cb6efdbb9b198cd531a0c
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
c0a8cd10a5829bf4e94ee073ba6f553128e9d8e9 |
|
19-Mar-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Text in accessibility events not consistent bug:2513822 Text added to accessibility events is truncated to max length. However, the fromIndex and toIndex properties are relative to the text before being truncated, thus potentially our of bound. Removed the max length limitation because test very rarely is longer that 500 characters and in the cases in which text is longer than 500 character it will not be a real problem to pass a bit more data through an IPC (very rarely). Change-Id: Ie70ac630dfeb56d4f59079abb2f46d07582796b6
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
9efd078c6bf513e8c6bf59ce57e6f9c038fdf3ee |
|
14-Apr-2010 |
Svetoslav Ganov <svetoslavganov@google.com> |
2593810 Accessibility event's parcelableData property not nullified during recycling Change-Id: I88d6f3d63d7ff0fbdd88fb9cb642349029838b31
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|
75986cf9bc57ef11ad70f36fb77fbbf5d63af6ec |
|
15-May-2009 |
svetoslavganov <svetoslavganov@google.com> |
Accessibility feature - framework changes (replacing 698, 699, 700, 701 and merging with the latest Donut)
/frameworks/base/core/java/android/view/accessibility/AccessibilityEvent.java
|