1. Fixed errors in the accessibility node cache.
A. The cache was not catching the case when the current window changes as a
result the user touch exploring it. As a result the cache had nodes from
more that one window but the node ids are not unique thus causing a mess.
B. The node info tree was prefetched regardless if a prefetched node is root
name space (i.e. view ids - not accessibility ids - are namespaced) while
the prefetched nodes were taking this into account. As a result there can
get disconnected subtrees in the cache.
C. When an event for a property change such as focus was received the cache
we were removing the source node. As a result there may be disconnected nodes.
D. When a node was added to the cache and an older version exists there was
no check if it will point to the same children and parent. As a result if
the state of the node has fewer children the subtrees rooted at the no
longer present children will stay disconnected in the cache.
E. When a node got accessibility or input focus the old one in the cache was
not removed. As a result you may have a state with more than one access
or input focus.
2. Added integrity check enabled only on user builds when a specific flag is set
for the cache which checks whether:
A. All nodes are from the same window.
B. All nodes are connected.
C. There are no duplicates.
D. There is only one input focus.
E. There is only one accessibility focus.
3. The reported accessibility node info tree was stopping at the root namespace
boundary which is not correct. The reported tree has to reflect everything
on the screen that the user can see such a workspace with widgets. The root
namespace is added to avoid clash of view id but the accessibility ids are
unique no matter if the view is inflated from a remote view.
4. Added calls to notify the accessibility layer when a preoprty that is interesting
for accessibiliy has changed.
bug:6471710
Change-Id: I069470d91f209ba16313fa6539787a55efa3512e
TargetDrawables now have a "home" position they can be scaled about.
Added new "focused" state to TargetDrawable. This is used to distinguish between highlight and selection.
Updated target icons to use new focused state. Currently re-uses "activated" icon.
Change to event handling to allow cancel events when a target is highlighted to cause a selection.
Cleaned up MultiWaveView initialization code.
MultiWaveView animation improvements:
- new scale animation when center handle is touched.
- switched to using indices instead of foreach loops in critical path code to avoid creating temporary objects.
- updated and simplified animation code.
Change-Id: I593c021475f1644c73bdb9f84855e6a9fec7c0ab
...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. Now the spinners in the time and data picker a wider therefore
easier to interact with, i.e. harder to miss accidentall.
2. Removed the scroll distance cut off user to distinguish between
fling and change by one.
3. Added visual feedback when the areas the serve as virtual buttons
in number picker are poked.
4. Removed the coeffcient that was making drap not to be one-to-one
with the scrolled distance.
5. Added some margin at the top and bottom of the spinners in
date and time pickers.
bug:6321432
Change-Id: I311c1733d1951b0563209401faa830ca70ec87cb
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
Use long instead of int so we don't run into a 2GB file limit.
Fix possible overflows in offset and length.
Change-Id: Idb3a34f5600f9c2372b9c89256f21757049fa43b
- 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
Bug 6453254
Don't allow a thread to be created with no recipients, by not calling
Threads.getOrCreateThreadId when there are no recipients.
Change-Id: Ia9b1e944db6da83a3e6caf2dcebece9fc52740b0
1. Delegating activation gestures has several issues that we should
decide how to handle if possible before allowing an accessibility
service to take over them:
A) It is needed that every view than can be clicked or long pressed on
reacts to such as a response to calling performClick and performLongPress
which is not necessary true since the view may watch the touch
events and do its own click long click detection. As a result it may
be possible that there are view a user cannot interact with in
touch exploration mode but can if not in that mode.
B) Clicking or long pressing on a different location in a view may yield
different results, for example NumberPicker. Ideally such views have
to implement AccessibilityNodeProvide which provider handles correctly
the request for click long press on virtual nodes. Some apps however
just fire different hover accessibility events when the user is over
a specific semantic portion of the view but do not provide virtual
nodes. Hence, a user will not be able to interact with such semantic
regions but the system can achieve that by sending the click/long click
at the precise location in the view that was last touch explored.
2. Adding a flag on accessibility service info to request explore by touch
mode. There is no need to put the device in this mode if node of the currently
enabled accessibility services supports it. Now the problem is inverted and
the service has to explicitly state its capability.
3. Fixing a bug where includeImportantViews was ignored for automation
services.
Change-Id: I3b29a19f24ab5e26ee29f974bbac2197614c9e2a
Changed the pokeWakelock() call back to take one argument - the duration to stay awake in ms. This
change was needed in order to poke the wakelock for the duration of the watchdog timeout. This
must be done in the service because the duration of the watchdog timeout is unknown at this point.
Moved pokeWakelock() from start() to handleServiceConnected() to make sure that this poke happens
before the poke in the service. This poke is still needed to account for when devices are rotated.
Change-Id: I19d62df1489514de0588ebb937678358e70ffc95
This problem was introduced in I74df9c24. The intention of the
change was still let UiTestAutomationBridge see the
non-important views, but there were bugs in the implementation:
1. AccessibilityManagerService was not really updating
mIncludeNotImportantViews when mIsAutomation is true
2. Wrong constant is used to set the flag
Change-Id: Ia0a2e9ed9720bd0ea3a563e0b492e870a6ec1586
In rewriteSingle(), catch Throwable to rollback to backup file,
instead of just IOException. Also add dumpAll() to pack up contents
for later debugging, and use it when encountering bad stats.
Bug: 6467868
Change-Id: Ic8e287cf5a235706811a304a88d71d11d3a79cd4
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
