Also add new methods to access the event timestamp in
nanoseconds. Hidden for now but useful for prototyping.
Bug: 6374616
Change-Id: I7030734a908e8e31a17a356debc269db7c0f0783
Bluetooth devices can be renamed by the user. Make the
input system aware of the user-specified name and transparently
pass it down to applications. This enables the keyboard
layout picker Settings UI to use device names that are
consistent with what the user set in the Bluetooth UI.
Bug: 6363157
Change-Id: I8eea26ce2c69c2a3f09c8de02e9e847610e0419c
When DHCP lease includes vendor info indicating that remote Wi-Fi
network is metered, advise NetworkPolicy. Users can still manually
change the metered flag in Settings.
Also remove any policies belonging to removed Wi-Fi networks, and
teach isNetworkMetered() about ethernet networks.
Bug: 6344821, 6369307, 6365872
Change-Id: I108606c6fddf2d02828fcab011f3a1501415f1bc
When a span with a visible influence on the text is modified, we only
need to invalidate the text sub display lists that overlap this span.
This is especially useful when typing and the composing span (an underline
span) gets updated after each key stroke.
Change-Id: Ib2af3219c41eb79ec5d0a2eee317aca8c4efdef9
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
NFC was not disabled/deinitialized when phone shutdown. This patch
add NFC disable on phone shutdown which can complete any pending
NFC transaction before phone shutdown.
Change-Id: Id1e604be7c34adec8623a1e526d8ff99e18bf74b
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
An editable TextView caches text rendering inside an adaptive
number of sub display lists. The bounds of these use to be those
of the entire View.
This CL creates block display lists with tighten bounds, so that
(a still-to-be-implemented) quick rejection can occur.
Also cleaned-up the contradictory translations that were used to
handle the TextView's internal scroll and removed the invalidation
of display lists in that case.
TODO: When internal scroll sets a tighter clipping rect, quick
reject the creation and display of the clipped display lists.
Also renamed blockEnds to a more explicit blockEndLines.
Change-Id: I7d79bea78d06d19b6935aef75ff7aa7df2594050
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
Bug: 5416822
The overload of webkitDraw is temporary, but this gets the plumbing
in place and works correctly
Change-Id: Ib3e23b9a4a1862dd445c8dc68a3936590787a62b
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
