...incorrect visibility when the ActionBar overflow menu is opened
Don't report layout flags in system UI visibility callback. Update
docs to reflect this.
Change-Id: Icfa411b5537de037cafbcac04991101e8b9138c4
1. Scrolling actions are crucial for enabling a gesture based
traversal of the UI and specifically scrollable containers
especially lists and anything backed by an adapter. Since
accessibility focus can land only attached views, it cannot
visit views for adapter items not shown on the screen.
Auto scrolling the list as a result of putting access focus
ot a list item does not work well since the user may get
trapped in a long list. Adding an accessibility node provider
to emit virtual views for one view before the first and one
after the last is complex and suffers the limitation of trapping
the user. Accessibility service need an explicit scroll actions
which may be performed upon an explicit user action. Hence,
the user is informed for the start/end of the visible part of
the list and he makes a deliberate choice to scroll. This will
benefit also people developing Braille devices since they can
scroll the content without telling the user to stop using the
Braille controller and take the device out of his pocket to scroll
and go back to the Braille controller.
NOTE: Without these action large portions of the screen will be
hard to access since users will have to touch and explore to
find and scroll the list.
Change-Id: Iafcf54d4967893205872b3649025a4e347a299ed
- Fading out recents first, then scaling up app
thumbnail
- Fade Recents out over 130ms
- Delay the window animation for 200ms first,
then animate for 200ms (previously we didn't delay
and then animated for 300ms)
Bug: 6390075
Change-Id: Ia8c753bf7ee03d2acef6eb2772b28d88fe10a682
If a fallback key is generated using a key plus a modifier,
then it's possible we might get a different fallback key
generated if the modifier has changed. PhoneWindowManager
needs to remember which fallback is last generated for a
given key code so that it can apply the same fallback action.
When generating cancellation events, it's important to have
preserved the policyFlags of the original event. Otherwise
we may not dispatch the cancellation properly. For example,
some actions are not performed if the POLICY_FLAG_TRUSTED
is not specified.
Remember the metaState associated with a key event so we can
include it when canceled.
Tell the policy when a fallback is being cancelled so that it
can clean up its state.
After a SEARCH shortcut is invoked, clear the flag indicating
that a shortcut is pending. This is to prevent SEARCH from
getting stuck down in the case where we might forget to send
the up. (Shouldn't happen anymore after the prior fixes.)
Bug: 5616255
Change-Id: I68f0a9679c7af464eaf31c099f2aa50b53fecf1f
The deferred invalidation of display list could cause problems with
view like TextureView who destroy resources when detached from the
window but only recreate them later at draw time. This would cause
temporary flashes or other visual glitches on screen.
Change-Id: I018488ba09743df21c6434ea610813014fb80a85
1. When a view that has accessibility focus is temporary detached
we try to draw the focus highlight and crash. Since the detached
view will be modified and then either attached or detached from
the window we should not keep accessibility focus on a temporary
detached view. Otherwise, we may have a scenario where the user
thinks he is in one item scroll acound and being in completely
different item because of the view being recycled but the user
has no clue.
2. Clearing accessibility focus when the view is removed from the
parent as opposed as when it is detached from the window. Since
we may have transitioning views for removal we do not want
accessibility focus on such views during the anumation.
bug:6457339
Change-Id: I62287a089ec6850fb1d691ae26dea54e1da39c94
1. AccessibilityNodeInfos for visible views should always
be reported and the clients should be able to check
whether that node info is shown to the user. For example,
focus search may return a node that is not on the screen
and the accessibility layer may decide to give it focus
which scroll the source view in the screen.
bug:6421991
Change-Id: Idc1fd8512dda767abe802aacedb0c69582e6fc2a
1. Implementing text content navigation at various granularities.
For views that have content description but no text the
content description is the traversed at character and word
granularities. For views that inherit from TextView the
supported granularities are character, word, line, and page.
bug:5932640
Conflicts:
core/java/android/view/View.java
Conflicts:
core/java/android/view/View.java
Change-Id: I66d1e16ce9ac5d6b49f036b17c087b2a7075e4c0
