1. Now the list traversal forward is the exact opposite
of the traversal backward.
2. The focus search starts from the view against which
the call is made as opposed to the one that has focus.
This is now consistent with the rest of the focus search.
bug:6537747
Change-Id: Ida6a696636a3099531155fcbff256f71264f5008
1. Iterators were skipping content on reversing direction.
2. The cursor was positioned at the beginning of the next text segment
when moving forward and at end of the previous text segment when moving
backwards. This is incorrect and now the cursor is positioned at the
end of the segment when moving forward and at the beginning when moving
backward.
3. The cursor position was not properly set when reaching the end/start
of the text.
4. The iterators were reporting strictly the next/previous segment even
if the cursor is within such a segment. Thus, when traversing some
content may be skipped. Now moving forward moves the selection to
the next segment end and the start position is either the old index
if it was within a segment or the start of the segment. Same in
reverse.
bug:6575099
Change-Id: Ib48a649cec53910339baf831a75e26440be6e576
Bug 6476578
The latest bug report show a query.length() of 33 while
mQueryTextView.length() is 0 on line 514.
I can see 2 reasons which can explain this discrepancy:
- the mQueryTextView has a filter, which alters the text.
- some asynchronous event (IME?) changes the text in the mean time.
I would favor the second one, which seems to break a lot of single
thread assumptions in the code and generates other IOOB exceptions.
Note that depending on what they are used for, it may be more consistent
to use mQueryTextView.getText() instead of query in the following
assignment.
Change-Id: Ie8a5486b11a80543f8f90980454933c5a74c073e
are pending
Save the pending position scroll until the data change is actually
serviced before posting it to run. This avoids handler loops on
GONE subtrees or when the view is detached.
Bug 6547649
Change-Id: Iab108cfcb7dd11ece703762d311a5f5985f38c3b
1. ActivityChooserView did not hide the popup window when detached.
bug:6544220
2. ActivityChooserView was calling show popup when it was already
showing it resulting in an incrrect update and losing one item
per rotation.
bug:6522041
Change-Id: Iec1682ca5d27e38caf57214fa86060edf82a2166
Delaying the popup by using removeView instead of removeViewImmediate
caused an error when the removal was actually executed after the parent
window was deleted along with the popup.
Fixes bug 6407801.
Change-Id: Ieb17d58467aaf16e1a24f47187f52766d694ba32
-> We cache RemoteViews which populate the AdapterViews, but only
up to a total memory amount of 2MB. The remainder of the cache
is pruned out. If _every_ item is greater than 2MB, we were failing
to prune the last item, leaving the framework in a loop on a bg
thread, but holding a lock required by the main thread.
Change-Id: I0574a25a59ebec6586ae223fff6605c0fee953c3
1. Now accessibility focus does not drag input focus and
vice versa. Having the two focuses chase each other
can lead to some pathological cases. For example, a
container is input focusable and manages input focus
for its children i.e. as soon as it gets input focus
it sets input focus to a child. Now assume input and
accessibility focus are on a child and focus search
finds the parent to take accessibility focus, now
putting accessibility focus to the parent will put
input focus there and the parent will put input focus
to the child which as a result will put accessibility
focus there, thus resulting in traversal loop.
bug:6522900
2. Fixed asymmetrical behavior of accessibility focus search
for AbsListView.
bug:6520016
3. Fixed accessibility focus search getting stuck in an
empty AbsListView.
bug:6520049
Change-Id: Ia26e5be7b5a9f340f873861ff466c787467b98dc
All these features have either been abandonned and left un-maintained
for years or can be replaced by systrace.
Change-Id: I42e4579a8078744047e5fe08a7a15254970b09bc
The only remotable method on TextView is setTextSize(float)
which assumes "sp" dimensions, making it tricky to get exact
text sizes.
Bug: 6519374
Change-Id: I961bbdd607ca6786c0630ff1ce19186f54f6f31f
1. Some accessibility actions should not be performed on disabled
views. For example, scrolling should not be permitted while
accessibility focus should be. Made a quick pass over the
actions we expose now.
Change-Id: I36626dfbc0d2f480309a910f58f1de64e9e05675
1. The prefetcher of accessibility nodes infos was not folloing
the childForAccessibility relationship when finding the views
whose node infos to prefetch.
2. NumberPicker was not reporting the correct parent.
bug:6471710
Change-Id: Ia7ad5dd031fb4b3816dfe630d5212201cfafa236
1. Added support for accessibility scroll action to
some widgets that are scrollable.
2. Making the super call when handling an accessibility
action in the views to call super first to allow
an accessibility delegate to intercept the call.
bug:5932640
Change-Id: I5eb37d64bf9fba1d5c596981132e0df717e2a18a
1. Finished the implementation of support for maintaining
accessibility focus in view with virtual descendants.
2. Finished the NumberPicker implementation of virtual
subtree such that all requred attributes are reported
and ensuring that it support accessibility focus in
its virtual descentants.
3. Fixed a bug where if a predecessor of the view that is
accessiiblity focused is removed the accessibliity focus
host in ViewRootImpl is not cleared leading to a crash
when trying to draw the accessibility focus highlight.:
bug:6472646
bug:6433864
Change-Id: I3645642b87b4a26025c0b2ba9dfaad92d11a48f1
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
