fed60953b09c6cd06f7b9579d103c94c0480ddf0 |
|
17-Sep-2013 |
Alan Viverette <alanv@google.com> |
Update AdapterView.performItemClick() documentation BUG: 10312828 Change-Id: I085326b336a799eeb26702dc30349e525c4f1023
/frameworks/base/core/java/android/widget/AdapterView.java
|
00dbe81fea7be57ee2ff8a97844faf1bc15a427f |
|
10-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Notification for changed subtree in accessibility mode not fired properly. We fire notifications that the a view subtree changed for accessibility. In some cases the notifications were fired if accessibility is not enabled. This is now fixed. Also the runnable for making the recurring subtree change was not dequeued if it was pending but we received a request which we decided to run immediately. bug:9337912 Change-Id: I27401b3d11f81c653e8761a704ee530263b08c3a
/frameworks/base/core/java/android/widget/AdapterView.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/widget/AdapterView.java
|
e5dfa47d84668376b84074c04570fb961870adeb |
|
09-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Improving accessibility focus traversal. 1. Now the views considered during the accessibility focus search are the ones that would get accessibility focus when thovered over. This way the user will get the same items i.e. feedback if he touch explores the screen and uses focus traversal. This is imperative for a good user experience. 2. Updated which focusables are considered when searching for access focus in ViewGroup. Generally accessibility focus ignores focus before/after descendants. 3. Implemented focus search strategy in AbsListView that will traverse the items of the current list (and the stuff withing one item before moving to the next) before continuing the search if forward and backward accessibility focus direction. 4. View focus search stops at root namespace. This is not the right way to prevent some stuff that is not supposed to get a focus in a container for a specific state. Actually the addFocusables for that container has to be overriden. Further this approach leads to focus getting stuck. The accessibility focus ignores root names space since we want to traverse the entire screen. 5. Fixed an bug in AccessibilityInteractionController which was not starting to search from the root of a virtual node tree. 6. Fixed a couple of bugs in FocusFinder where it was possible to get index out of bounds exception if the focusables list is empty. bug:5932640 Change-Id: Ic3bdd11767a7d40fbb21f35dcd79a4746af784d4
/frameworks/base/core/java/android/widget/AdapterView.java
|
f937313944e0e9dfa4375a275710e420c2a92554 |
|
16-Apr-2012 |
Mindy Pereira <mindyp@google.com> |
Perform null check on empty view before doing accessibility check. Fixes b/6341858 AdapterView does not properly check for null before checking empty view accessibility info Change-Id: Ia19fdef2c7c5f3e6c3053ebc754efe6a664f9d66
/frameworks/base/core/java/android/widget/AdapterView.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/widget/AdapterView.java
|
8a78fd4d9572dff95432fcc4ba0e87563415b728 |
|
17-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityEvent/AccessibilityNodeInfo class name property should be set to only framework classes. AccessibilityEvent and AccessibilityNodeInfo have a property className which is set to the source Java class. This is problematic since leads to leaking private classes which would allow an accessibility service to load classes from other packages. This is strongly undesirable since not trusted code can be loaded, and hence executed, in the accessibility service. To address that the class name is set to the most concrete framework class extended by the info/event source. bug:5878943 Change-Id: I7b3114ece8772ea2773f5151e21b8a6f2006882a
/frameworks/base/core/java/android/widget/AdapterView.java
|
61fd1e8d8c3ccf2d6b7d4af1c19e8f0988d5a1ec |
|
26-Oct-2011 |
Joe Fernandez <joefernandez@google.com> |
docs: add developer guide cross references, Project ACRE, round 3 Change-Id: I6125315ecdf0f78dd947c514a9944729d723e95d
/frameworks/base/core/java/android/widget/AdapterView.java
|
0e6fa8b60d113883c92dd754f5e3f8bb8b17e073 |
|
19-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
AdapterView does not check for null adapter when initializing accessibility event. The code that initializes accessibility events was assuming the AdapterView always has an adapter and this caused NPE. Now the right method of the view is called to get the item count. bug:5474162 Change-Id: I6c330dc2894477df9447a4ecfddc7bd62c575d59
/frameworks/base/core/java/android/widget/AdapterView.java
|
a72a80632b07dd7faf0ca2a4a0eae2770b14caa6 |
|
11-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "DO NOT MERGE AdapterView does not set setCurrentItemIndex in accessibility event." into ics-mr0
|
eb0c52e491d89543d0e9573b81fdb9145d680059 |
|
11-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
DO NOT MERGE AdapterView does not set setCurrentItemIndex in accessibility event. Cherry picking since branching caught us in the middle of review. bug:5439637 Change-Id: I67d080abb4c14cad88b952e2f91d65e181b2029b
/frameworks/base/core/java/android/widget/AdapterView.java
|
98348517fde86f993b5720a862bce5c2a5f1a06f |
|
11-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
DO NOT MERGE AdapterView#isScrollableForAccessibility does not handle null adapter. Cherry picking since branching caught us in the middle of review. 1. If an AdapterView has no adapter and the view tries to fire an accessibility event we get a null pointer exception. bug:5439321 Change-Id: Ia3d7a5ad852ef42422d10d8a62c4d3af6792313b
/frameworks/base/core/java/android/widget/AdapterView.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/widget/AdapterView.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/widget/AdapterView.java
|
b84b94e1a04cd1f396dd6fef98d65ca1a2729c92 |
|
23-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Scroll accessibility events should not populate text. Scroll events are used to report position change and should not contain the text content of the view that fires them because it is usiually a containter for many other views and the text will be long and not informative for accessibility purposes. Also such evens are fired relatively frequently. If a client wants to fetch some textual content for a scroll event he can use the interrogation APIs. bug:5352059 Change-Id: I43e02aca895c8ab16ba82ebe1cee3aea8ce7711a
/frameworks/base/core/java/android/widget/AdapterView.java
|
cbff417962b06cb2d80fe8efe8de31482e7bfcbb |
|
19-Sep-2011 |
Adam Powell <adamp@google.com> |
Fix bug 5143751 - cts errors in android.app.cts.AlertDialog_BuilderTest Change-Id: Ic532785d2c52bf65c3884665ffc53aabdf3253b9
/frameworks/base/core/java/android/widget/AdapterView.java
|
f18c8ddd0f466de4b2f819fbbd612949bd71c532 |
|
17-Sep-2011 |
Romain Guy <romainguy@android.com> |
Clarify documentation of AdapterView.OnItemSelectedListener Bug #5331587 Change-Id: Ic3d6aca573639d6cae3abb45bfe821f5fd31f1bc
/frameworks/base/core/java/android/widget/AdapterView.java
|
031d9c1389de2b9dac7f175af0b962e24b21d5be |
|
10-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding accessibility delegate mechanism for backwards compatibility support. 1. Added an AccessibilityDelegate class in View which can be set by a client that wants to cutomize accessibility behavior via composition as opposed to inheritance. Insead overriding a new method in View thus being bound to the API version that introduced this method a developer can conditionally inject the accessibility customization if the platform API version is heigh enough. The developer will have to override the method of interest of the delegate. The default implementation of the delegate methods is the same as that of View in the case that there is no delegate set. If a delegate is set calling an accessibility related method on View will be handed off to the corresponsing method of the delegate. bug:5259555 Change-Id: I00e750e22e5e7164a1b571cb3d12ecaf4ab93db4
/frameworks/base/core/java/android/widget/AdapterView.java
|
aacbf9111b58f10f7474fbd3a8debb02713f8b18 |
|
08-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Not visible view should not be announced or interacted with."
|
0b0a41d8e26eaf0f1d9d922621494daf40964a9a |
|
08-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Not visible view should not be announced or interacted with. 1. Some invisible views' text was reported by accessibility events. 2. Accessibility actions could have been perfromed on invisible views. bug:5264355 Change-Id: I68184fb436a3e10e947ec6f1eae02aa3d0d1cb7f
/frameworks/base/core/java/android/widget/AdapterView.java
|
aa56534722a4972428e3d16b8e64caaea565a715 |
|
06-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
AbsListView does not populate accessibility events correctly. The toIndex of accessibility events fired from a AbsListView is exclusive but should be inclusive i.e. it was reported one more that it has to be. bug:5256286 Change-Id: I496959fdfb6760b0c74899730c4cc558e89234a6
/frameworks/base/core/java/android/widget/AdapterView.java
|
c48c47c8206251800e9c6768db5c7aef2fe301e8 |
|
02-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility events fired from AdapterView underpopulated. Accessibility events fired by an AdapterView did not report the index of the first and last visible items, rather only the total item count. bug:5225039 Change-Id: I6931d82f0418c659f26e1e8a345da69da99690c5
/frameworks/base/core/java/android/widget/AdapterView.java
|
8c6c79f0909ceabeb8abe1013648c31c7582b7ad |
|
30-Jul-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding a callback to ShareActionProvider + make ActivityChooserView popup hide on action bar hide. 1. Added a callback to ShareActionProvider allowing clients to be notified when an activity is chosed given them a change to say update their UI and also decide whether to handle the activity launch themselves. 2. The popup of the ActivityChooserView was not hiding on hiding the action bar. bug:5094963 bug:5095004 Change-Id: I6c8e8cc1f22d07e707e2218eb108f9101417b23b
/frameworks/base/core/java/android/widget/AdapterView.java
|
9ea764f159a8b0f1180a939d0800587900bdbc07 |
|
30-Jul-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
No selection or click accessibility events are fired when a list item is tapped. 1. It appears that this was never working!? bug:5098631 Change-Id: I37cd93e6e94137918a2cade13f24846563b23633
/frameworks/base/core/java/android/widget/AdapterView.java
|
6179ea3196e9306d3f14361fe9ef14191b1edba6 |
|
28-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding accessibility support to the Status Bar. 1. Added content description to pretty much all animals in the zoo including buttons in the navigation bar, notifications and status icons for battery, signal, data, etc. 2. Rectored to avoid ovelaying views since they block touch exploratino. In general overlaying views cause trouble for touch exploration and accessibility in general. 3. Avoid sending accessibility events in case the user is touching outside of the StatauBAr panels to avoid confusion. 4. Added records to accessibility events in the places where this would help the presentation. So the event comes from a given "leaf" view and its predecessor is adding a record to the event for itself to provide more cotext. It is up to the accessiiblity service to choose how to present that. bug:4686943 Change-Id: I1c1bd123d828fb10911bca92130e9a05c1f020b3
/frameworks/base/core/java/android/widget/AdapterView.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/widget/AdapterView.java
|
bad9d97693a784ea37f1510550e0e4a98f9a9180 |
|
28-May-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Refatoring a bit of accessibility code Change-Id: I4df1741b622b21176c10311da0dc6347ca6fb390
/frameworks/base/core/java/android/widget/AdapterView.java
|
30401328c1026389171d454c934c15875c3f7ff0 |
|
13-May-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Factored out the Accessibility vertical initialization. 1. Accessibility events were filled with data in dispatchPopulateAccessibilityEvent and onPopulateAccessibilityEvent. These events have two axis of population 1) up the class hierarchy to populate information for the event source; 2) down the view hierarchy to populated all the text contained in the source including its descendants. These two axis of population were done in on population pass now the populating the source properties happens in initializeAccessiblityEvent and the text in onPopulateAccessibilityEvent which is called from dispatchPopulateAccessiblityEvent. 2. Removed the string description from events fired from CompoundButton since the event has isChecked() property and it is responsibility of the clients to decide what utterrance to use and if to use such for announcing the checked state. Change-Id: I5d7f75cf8a87a7a4b3bb7b311e8e642ec9a0faa5
/frameworks/base/core/java/android/widget/AdapterView.java
|
887e1a17eb9b12448f5929791b564565b2665aab |
|
30-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration - nits Change-Id: Ie49558e0a81218dbad70c02f81dd7a59b3213d5c
/frameworks/base/core/java/android/widget/AdapterView.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/widget/AdapterView.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/widget/AdapterView.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/widget/AdapterView.java
|
079e23575024e103358c982152afb7a720ae1a8a |
|
19-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Add new fade in/out feature for drawable containers. This is used to allow list view's pressed and activated indicators to fade in an out, though of course it can be used elsewhere as well. There is a lot of complexity in supporting this in list view. The two main things that are being dealt with: - When recycling views, we need to make sure that the view's drawable state doesn't get animated from an old row's state. The recycler now keeps track of which position a view was last in, and if it is reused at a new position there is a new View/Drawable API to tell it to jump to its current state instead of animating. - For the pressed indicator to fade out, we need to keep displaying it after it is hidden. There are new variables and code to keep track of this state, and tweaks in various places to be able to remember the last selected position and continue updating the drawable bounds as needed. Change-Id: Ic96aa1a3c05e519665abf3098892ff2cc4f0ef2f
/frameworks/base/core/java/android/widget/AdapterView.java
|
5e25c2c14593caee5638603120553ae1ec530f85 |
|
16-Sep-2010 |
Chet Haase <chet@google.com> |
Add ability to automate animated transitions on View show/hide Change-Id: Id6ff92c8fd06c3f5fb30c41b020b4de4f567154f
/frameworks/base/core/java/android/widget/AdapterView.java
|
e30e1ff8bce5bc74555d34fc13d00c548c1ca24e |
|
31-Aug-2010 |
Adam Powell <adamp@google.com> |
am 7d04f2bc: am 4c72ad75: Merge "Fix bug 2918587 Infinite loop and memory leak in AdapterView" into gingerbread Merge commit '7d04f2bc4e38d5d7d2b37d6dec76fb3793311341' * commit '7d04f2bc4e38d5d7d2b37d6dec76fb3793311341': Fix bug 2918587 Infinite loop and memory leak in AdapterView
|
9c17a4c11005877b65d841f4fbd810df89c7c206 |
|
31-Aug-2010 |
Adam Powell <adamp@google.com> |
Fix bug 2918587 Infinite loop and memory leak in AdapterView Change-Id: Icb63b186c56c2d731003dc38a8ff7a93a69a94e7
/frameworks/base/core/java/android/widget/AdapterView.java
|
1480fddea874a42adb43b4bcdac6704e4c3e110b |
|
26-Aug-2010 |
Adam Cohen <adamcohen@google.com> |
-> Added the ability to specify an AdapterView's empty view through RemoteViews. An empty view is the view that appears in lieu of the collection when the collection is empty. -> Made StackViews start at their last item Change-Id: Ica44e5e8f8f2a2e5589a6c74414ec4d08303887f
/frameworks/base/core/java/android/widget/AdapterView.java
|
bea95162ca25bd00b0479d93739b6283795c3986 |
|
11-Aug-2010 |
Konstantin Lopyrev <klopyrev@google.com> |
Categorizing exported view properties. Change-Id: I79c42019836973d80662c21d195d088ae01537a0
/frameworks/base/core/java/android/widget/AdapterView.java
|
76879bc2343779d4d2a870b7bd46b0544c0cc46c |
|
15-May-2009 |
svetoslavganov <svetoslavganov@google.com> |
resolved conflicts w/ 75986cf9bc57ef11ad70f36fb77fbbf5d63af6ec merge....
|
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/widget/AdapterView.java
|
b6af533114cfa5a4547990e79e96bd0402c47e72 |
|
28-Apr-2009 |
Mihai Preda <preda@google.com> |
Allow ViewStub to be used in AdapterView.setEmptyView() (bug 1803058)
/frameworks/base/core/java/android/widget/AdapterView.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/widget/AdapterView.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/widget/AdapterView.java
|
f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/widget/AdapterView.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/widget/AdapterView.java
|