Introduce new AssistData class that contains all data
the framework automatically generates for assist. Currently
populated with a very simple tree structure representing
the app's view hierarchy.
Reworked how we populate the class name for accessibility
info, so this is provided through a new method call on View
that subclasses can override. This method is also used
to populate the class name in AssistData.
Change-Id: Ibd0acdc8354727d4291473283b5e4b70894905dc
Adds a systemUiVisibility flag and links it
to the status bar icon controller. Also adds a
theme attribute for setting the flag.
Bug: 19233606
Change-Id: I8a89a10cf2746cefa2feba50dc60c5eccd2ab28d
This CL creates the Type attribute for ActionMode, which will serve as a flag to determine its behavior and representation.
- TYPE_PRIMARY is the default and will maintain the current behavior and representation in the ActionBar
- TYPE_FLOATING will be the new Type and will be represented as a Floating Palette
Editor switches the flag from the default to TYPE_FLOATING, but this has no consequences right now, until the functionality is implemented.
Change-Id: Icd6cab01637f6ca3ae2e999b06904e08974d0c81
We were using an approximation to determine where to send a pair of down
and up events to click on the view that has accessibility focus. We were
doing reverse computation to figuring out which portion of the view is
not covered by interactive views and get a point in this region. However,
determining whether a view is interactive is not feasible in general since
for example may override onTouchEvent. This results in views not being
activated or which is worse wrong views being activated.
This change swithes to a new approach to activate views in accessibility
mode which is guaranteed to always work except the very rare case of a
view that overrides dispatchTouchEvent (which developers shouldn't be
doing). The new approach is to flag the down and up events pair sent
by the touch explorer as targeting the accessibility focused view. Such
events are dispatched such that views predecessors of the accessibility
focus do not handle them guaranteeing that these events reach the accessibiliy
focused view. Once the accessibiliy focused view gets such an event it clears
the flag and the event is dispatched following the normal event dispatch
semantics.
The new approach is semantically equivalent to requesting the view to perform
a click accessiblitiy action but is more generic as it is not affected by
views not implementing click action support correctly.
bug:18986806
bug:18889611
Change-Id: Id4b7b886c9fd34f7eb11e606636d8e3bab122869
Previously we only used direct visibility, which resulted in strange
behavior when a parent view with an animated child was hidden. We were
also incorrectly awakening scroll bars for non-visible views, though
that's a much less visible (pun intended) bug.
Only handles the two most common cases for ripples. A subsequent CL will
update handling of View drawable management and fix this for all managed
drawables.
Bug: 15350931
Change-Id: I0d0fe2c51210e8d2e0a73b0248cec3b93bfc36f5
Allows framework-added windows to manually specify surface insets, which
enables us to wrap the popup window's elevated content view with a root
view, which in turn allows us to use the Transition API for popup window
transitions.
Fixes a bug where the root view's render node forced clipping.
Bug: 13211166
Change-Id: I303dfa55a052cdf5d3b1485422529123e3cc867a
AccessibilityNodeInfo refresh was getting the latest cached
state but this is not good enough as an accessibility service
can execute an action on the node and then refresh it to get
the new state.
bug:16954787
Change-Id: I004b4987b8dc423a2ab7031a4fbfe64365ddd7fe
AccessibilityInteractionController checks window visibility during focus
search and when performing an action, which prevents the framework from
clearing focus when windows lose visibility. This change ensures that
focus will already have been cleared, which matches the behavior of the
other properties checked during focus search (view detachment and view
visibility).
Bug: 19169643
Change-Id: I795ed27ce8dfb7ecb1462943c81c5b14973a8d7a
bug:19113359
Ensures that ViewOutlineProvider#PADDED_BOUNDS is always kept up to
date with the view's padding.
Change-Id: I5e090bd8272e89d6b8b9055dbe95ef3d45333fcb
To click a view we were computing a click location by ignoring overlapping
views that are actionable. However, detection whether a view is actionable
is not always possible as the view may handle touch events directly. This
leads to unhandled edge cases. We are taking a conservative approach and
ignore all overlapping siblings regardless if clickable. This is also has
limitations but hopefully less frequent edge cases.
bug:18889611
Change-Id: Icea0b7b3e2d4ed53e50e01cb6a99b880be560b14
automerge: 9027d73
* commit '9027d7355e8e804307902fb5ec88cf54e23cdcb4':
Accessibilty: Cannot click on views in a scrollable container covered by the toolbar.
