| 99a82437ed8e0537d9a355a124d2bb30aea46ad8 |
|
25-Oct-2014 |
Svet Ganov <svetoslavganov@google.com> |
Printing from two apps at the same time not working.
When printing from two apps at the same time the second print UI is
getting stuck. There were a couple of issues here:
AdapterView was not notifying for item selection if the data changes
after scheduling a dalayed selection notification and the notification
execution. The code assumed that a layout pass will occur and posponed
the notification after the layout pass but it is not guaranteed that
such a layout pass will occur. Now we delay only if a layout pass is
being scheduled.
Also when binding to the PDF rendering service the print spooler was
using the same intent and as a result two print activites were getting
the same renderer instance while they should get separate ones. Now
we use different data in the intent to ensure we get separate renderer
instances.
Change-Id: I6aa7c7b041957804b4273549dd837a6d70064efc
/frameworks/base/core/java/android/widget/AdapterView.java
|
| ec8e720ae209d975ac34dc66e51f280d9a9482ef |
|
07-Oct-2014 |
Alan Viverette <alanv@google.com> |
Ensure AdapterView doesn't post selection notifications forever
Previously we would loop forever if a selection notification was
posted after data had changed but the data changed bit was never
reset (e.g. a layout pass never occurred). This moves the pending
notification to occur as part of a layoutChildren() /
checkSelectionChanged() pass. If the client does horrible things
to prevent layout, no notification will occur -- but we won't loop
forever.
BUG: 17736536
Change-Id: I9773a769ad402c92dcbe2af7b8982d4443001961
/frameworks/base/core/java/android/widget/AdapterView.java
|
| 996a63859fd6e1e77f88ae465afa2c71e4dd3245 |
|
03-Sep-2014 |
Alan Viverette <alanv@google.com> |
Fix accessibility events emitted from TwoStatePreference
Removes redundant and conflicting events emitted from check and switch
preferences. Sends VIEW_CLICKED accessibility events from AdapterView
rows after calling their on click listeners, which ensures data is
consistent.
BUG: 16961152
Change-Id: I4b57bceec6830d775c2da57226b8ee482242caf7
/frameworks/base/core/java/android/widget/AdapterView.java
|
| 449e46600f75a21975ceb1c991f768f833ed7fbf |
|
21-Feb-2014 |
Elliott Hughes <enh@google.com> |
am 0047d3e0: am e253b514: am 29d60b95: am 8d41e653: Merge "Miscellaneous small documentation fixes."
* commit '0047d3e025b43fd2dc05734f7ea6229291445046':
Miscellaneous small documentation fixes.
|
| 9525f2a72e2786f1b53927878dd8234859ea5c39 |
|
02-Jan-2014 |
Mark Doliner <markdoliner@google.com> |
Miscellaneous small documentation fixes.
Most of these I noticed on my own. The change to docs/html/tools/testing/testing_ui.jd is mentioned in a bug report:
https://code.google.com/p/android/issues/detail?id=56324
Signed-off-by: Mark Doliner <markdoliner@google.com>
/frameworks/base/core/java/android/widget/AdapterView.java
|
| 5fbd62b3999158a8639d772f5f8e337756ad26b2 |
|
24-Sep-2013 |
Alan Viverette <alanv@google.com> |
am 36055c33: am e1cb9acc: Merge "Update AdapterView.performItemClick() documentation" into klp-dev
* commit '36055c3396051e1f1e0257b9e98c0b9b5ac16080':
Update AdapterView.performItemClick() documentation
|
| 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
|
| d6479ec5eec13914f656f6be996d95fe1610fd57 |
|
11-Sep-2013 |
Alan Viverette <alanv@google.com> |
Clean up layout constructors, make them consistent
All constructors now flow through to each class's own 4-argument
constructor. This ensures that theme attributes are applied even
if a base AttributeSet is not provided.
BUG: 10680863
Change-Id: I727d2961bf017c6a5e0206367081670782583394
/frameworks/base/core/java/android/widget/AdapterView.java
|
| 617feb99a06e7ffb3894e86a286bf30e085f321a |
|
10-Sep-2013 |
Alan Viverette <alanv@google.com> |
Add View constructor that supplies a default style resource
Also updates the constructor of every class that extends View.
BUG: 10676369
Change-Id: Ifaf27bf82028d180afa4931c0e906df88d858ac3
/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
|