1. The old introspection model was allowing querying only the active window
which is the one the user is touching or the focused one if no window is
touched. This was limiting as auto completion drop downs were not inspectable,
there was not way to know when the IME toggles, non-focusable windows were
not inspectable if the user taps them as until a screen-reader starts
introspecting the users finger is up, accessibility focus was limited to
only one window and the user couldn't use gestures to visit the whole UI,
and other things I can't remember right now.
The new APIs allow getting all interactive windows, i.e. ones that a
sighted user can interact with. This prevents an accessibility service
from interacting with content a sighter user cannot. The list of windows
can be obtained from an accessibility service or the host window from an
accessibility node info. Introspecting windows obey the same rules for
introspecting node, i.e. the service has to declare this capability
in its manifest.
When some windows change accessibility services receive a new type
of event. Initially the types of windows is very limited. We provide
the bounds in screen, layer, and some other properties which are
enough for a client to determined the spacial and hierarchical
relationship of the windows.
2. Update the documentation in AccessibilityService for newer event types.
3. LongArray was not removing elements properly.
4. Composite accessibility node ids were not properly constructed as they
are composed of two ints, each taking 32 bits. However, the values for
undefined were -1 so composing a 64 long from -1, -1 prevents from getting
back these values when unpacking.
5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added
a check that enforces such trees to be well formed on dev builds.
6. Removed an necessary code for piping the touch exploration state to
the policy as it should just use the AccessibilityManager from context.
7. When view's visibility changed it was not firing an event to notify
clients it disappeared/appeared. Also ViewGroup was sending accessibility
events for changes if the view is included for accessibility but this is
wrong as there may be a service that want all nodes, hence events from them.
The accessibility manager service takes care of delivering events from
not important for accessibility nodes only to services that want such.
8. Several places were asking for prefetching of sibling but not predecessor
nodes which resulted in prefetching of unconnected subtrees.
9. The local AccessibilityManager implementation was relying on the backing
service being ready when it is created but it can be fetched from a context
before that. If that happens the local manager was in a broken state forever.
Now it is more robust and starts working properly once the backing service
is up. Several places were lacking locking.
bug:13331285
Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
This is a cherry-pick of https://googleplex-android-review.git.corp.google.com/#/c/399886/
Instead of storing a kb layout per device descriptor (which is expected
to be unique), store it for each vendor/product. This way we can keep
a consistent layout between identical but physically different keyboards.
There are some corner cases this is expected to fail on, namely devices
that incorrectly have the same vendor/product id. Devices that don't
define a vendor/product id will continue to use the descriptor to store
layout files.
Change-Id: I1f2508561992080459310d5a644dad65a9c24f1a
Allow device overlays to override the behavior of the
hasPermanentMenuKey method at build time. This is useful for devices
that do not behave as the usual autodetection mechanism expects.
Device overlays should set config_overrideHasPermanentMenuKey to 1 if
the device DOES have a permanent menu key or 2 if the device DOES NOT
have a permanent menu key.
Bug 11698700
Change-Id: I467b68528cf681b08adcaebc2402d8bdd84f6b5c
Extract the size from the MeasureSpec value before adding the
delta. The opposite order could result in a negative delta causing
overflow into size from the EXACTLY mode, creating a very large size
value in the resulting MeasureSpec.
Don't reapply optical bounds insets after pulling a value from the
measurement cache. (The insets will have already been applied before
insertion into the cache.)
Change-Id: Ib0154f4d6c3a7c31e7fee24fd7d5d10cc5dc71a1
Bug: 13360343
Change DisplayList to be more forgiving with weaker lifecycle
requirements. Is more self-managed with a strong reference
to the renderer it needs
Also fix naming mismatch
Change-Id: I5c89453a72a52954f6f959f0846199705dbb6476
These new keys behave in similarly to KEYCODE_POWER but do not
simply toggle between awake and asleep states.
Sleep puts the device to sleep if it is awake.
Wakeup wakes up the device if it is asleep.
Bug: 12938999
Change-Id: I260fb918cc858882fe06fa880910df5763a76c5d
Bug: 13338698
Move the releasing of hardware resources to a new
@hide onDetachedFromWindowInternal
Change-Id: I52b4e6ba4d5b3ce20b89cabffa248d1d780e3e81
This CL introduces InputMethodSubtypeArray which compresses
multiple instances of InputMethodSubtype to reduce the risk
of TransactionTooLargeException during IPCs.
There are some IMEs which rapidly adding new subtypes into
their supported language list. One problem here is that each
instance of InputMethodInfo internally owns the list of
supported subtypes. Basically it requires additional
200 ~ 300 bytes for each subtype when InputMethodInfo is
transffered via IPCs. We should keep the size less than
100 KB in typical scenario.
With this CL, the list of InputMethodSubtype is marshalled
with GZIP compression. Approximately one InputMethodInfo is
marshalled within 10 KB even when it has 100 subtypes.
No negative performance impact is observed so far. The cost of
decompression seems to be compensated by another optimization
in this CL. Actually marshalling cost is reduced with this CL
by caching the compressed data on demand.
BUG: 12954290
Change-Id: Ibb2940fcc02f3b3b51ba6bbe127d646fd7de7c45
