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
1. The accessibility focus directions are not needed since an
accessibility service just get the root, first child, next
sibling, previous sibling and call execute the action to
give it accessibility focus. Now the accessibility node
info tree is properly ordered taking into account layout
manager directions for both layout manager that we report
and ones that we have determined as not important for
accessibility. Also the position of a node info are ordered
properly based on their coordinates after all transformations
as opposed to child index.
bug:5932640
Change-Id: I994a8297cb1e57c829ecbac73a937c2bcbe0bac7
Bug #6365056
WebView enqueues a functor in the hardware renderer to handle
animations and this functor is called at a later time by the
hardware renderer. However, the functor was not removed from
the queue when WebView was removed from the window. This could
cause the hardware renderer to attempt to execute an invalid
functor and lead to a crash.
Change-Id: I9d38e80f3fdc5e29d4d0cdfa1e893c251a954508
Will also fix Bug 6344997
The previous TextWatcher mechanism was inneficient. It require an
expensive getSpans() call to retrieve all the spans and then search
for the one we're interested in in case it has been changed.
The SpanWatcher is faster, it will broadcast the add/changed/removed
events we're interested in.
Now that we can rely on SpanWatcher, use it to directly track
addition and removals of EasyEditSpans.
No unit test for this feature which require an integration with
the voice IME. Easy to test manually though.
Change-Id: Idabcacc48c479bf9868d5204c0b0ca709207ede2
This flag was still hanging around pending any need to disable
DisplayList properties. But things seem stable, so it's time to clean up
and simplify the code.
At the same time, I reduced redundance in DisplayList dimensions. We
used to call drawDisplayList() with width/height parameters that were
used to do a clip reject. This is redundant with the DisplayList properties
that set the bounds of the DisplayList; the left/right and top/bottom properties
represent the same width/height properties formerly used in drawDisplayList().
The new approach is to not pass dimensions to drawDisplayList(), but to
instead pull those dimensions directly from the DisplayList when needed.
Change-Id: I8871beff03b1d4be95f7c6e079c31a71d31e0c56
Also add new methods to access the event timestamp in
nanoseconds. Hidden for now but useful for prototyping.
Bug: 6374616
Change-Id: I7030734a908e8e31a17a356debc269db7c0f0783
1. A view that creates an accessibility node info may add to the info
a list of granularity labels. These are granularities by which the
source view can iterate over its content. For example a text view
may support character, word link while a web view may additionally
support buttons, tables, etc. There are actions on accessibility
node info to go to the next/previous at a given granularity which
is passesed as an argument.
2. Added Bundle argument to the APIs for performing accessibility
actions. This is generic and extensible.
bug:5932640
Change-Id: I328cbbb4cddfdee082ab2a8b7ff1bd7477d8d6f9
1. An accessibility service has to explicitly opt in to be notified
for gestures by the system. There is only one accessibility service
that handles gestures and in case it does not handle a gesture
the system performs default handling. This default handling ensures
that we have gesture navigation even if no accessibility service
would like to participate/customize the interaction model.
bug:5932640
Change-Id: Id8194293bd94097b455e9388b68134a45dc3b8fa
1. The AccessibilityInteractionController was using an incorrect
looper i.e. not the UI thread looper which was causing getting
the root node to fail.
2. The AccessibilityNodeInfo was populated by a ViewGroup with the
children for accessibility without checking whether these children
are really displayed.
bug:6362875
Change-Id: I7906d89571eb9d57d10f971639f88632926dd077
When views are removed from a view or a view is detached from
a window, we need to update the touch and hover targets appropriately.
Failing to do this resulted in a NPE while dispatching an
ACTION_HOVER_EXIT to a view that had previously been removed.
Removed views should not get input events.
Change-Id: I4af4f8e2c4028347d3f570894fd1b3b366d11455
A View that is not attached will place posted actions on the
ViewRoot's runQueue. Previously, this runQueue was only ever executed
during a layout (during performTraversals()). This works in most situations
(a View that is added to or removed from the hierarchy will force a layout
in general), but not in all cases. For example, a new View being added to
a ListView will not cause a layout, so any actions posted to that View
prior to its being attached will not be run until some indeterminate time
later when a layout happens to run.
The fix is to execute the (typically empty) runQueue on every traversal.
Issue #6366678 View.post() ignored when called on an unattached ListView item
Change-Id: I94e6fdd9da6bb57fd83b547f8d742cd0ddfecbd6
ViewPropertyAnimator now sets the hasTransientState flag in View to tell
it when an animation has started (and unsets it when the animation ends).
This allows ListView to retain views with transient state without recycling them,
which makes ListView item animation possible (because you can't animate a View
if it's being recycled and reused elsewhere as it moves into and out of view).
Change-Id: I75c26a7a56474a76428500afef03a80bb46e04e0
The refactor of ViewGroup.drawChild() resulted in an error
in a new method (View.drawAnimation) where animations were being
initialized with their view dimensions instead of the parent dimensions.
Issue #6292681 RotateAnimationTest#testRotateAgainstPoint fails on JRN04
Issue #6293275 TranslateAnimationTest#testInitialize fails on JRN04
Change-Id: Ia90711cadd7a6c20fd788e5b8b18a5b28551e68c
The '^', '`', and '~' characters that we use for circumflex,
grave and tilde accents are ugly. Use the appropriate printing
modifier characters instead.
Bug: 6110399
Change-Id: I53891139ed1cef3010f5319ff49df1eeb1c6feeb
1. Added more gesture for accessibility. After a meeting
with the access-eng team we have decided that the current
set of gestures may be smaller than needed considering
that we will use four gestures for home, back, recents,
and notifications.
2. Adding actions for going back, home, opening the recents,
and opening the notifications.
3. Added preliminary mapping from some of the new gestures
to the new actions.
4. Fixed a bug in the accessibility interaction controller
which was trying to create a handled on the main looper
thread which may be null if the queried UI is in the
system process. Now the context looper of the root view
is used.
5. Fixed a bug of using an incorrect constant.
6. Added a missing locking in a couple of places.
7. Fixed view comparison for accessibilityt since it was
not anisymmetric.
bug:5932640
bug:5605641
Change-Id: Icc983bf4eafefa42b65920b3782ed8a25518e94f
1. Views that a user cannot see should not be reported for
accessibility. The check for zero alpha was missing.
bug:6291855
Change-Id: I3cb4c19cccf0dc2427677df630d124c36bd4770b
Bug: 6347083
Fix an issue where enterTouchMode would remove focus from the
view that already has focus and is focusableInTouchMode. This
causes issues with WebView, as it updates internal state when
losing and gaining focus.
Change-Id: I5c1f72cc08baf3445e2be9e0496606a53fb9929e
LayoutTransition used to depend on child views being added/removed or
shown/hidden in the transition container. These evens would trigger animations
to fade the child view as well as those to animate the side-affected changes
to sibling views. This CL enables a new feature in LayoutTransition that
enables animating any changes to the layout of the children in the container
whenever a layout occurs. For example, you can change the LayoutParams of a
child view and call requestLayout() to automatically animate those changes.
This capability is not enabled by default. To enable, call the new
LayoutTransition.enableTransitionType(LayoutTransition.CHANGING) method.
Change-Id: I4d07a3b36245353b2151f0dca4f75080ab6a4592
