Bug: 5156144
Input channels could leak or simply live longer than they should
in some cases.
1. Monitor channels (used by the pointer location overlay) are never
unregistered, so they would leak.
Added code to handle failures in the receive callback by closing
the input channel.
2. The DragState held onto its input window and application handles
even after the input channel was disposed.
Added code to null these handles out when they are no longer needed.
3. Input channels previously used as input event targets would stick
around until the targets were cleared (usually on the next
event).
Added code to detect when the input dispatcher is in
an idle state and to proactively clear the targets then
to ensure that resources are released promptly.
4. Native input window handles held onto the input channel even
after the input window was removed from the input dispatcher.
Consequently, the input channel would not be disposed until
the input window handle itself was freed. Since the input
window handle is held from managed code, this meant that the
window's input channel could stick around until the next GC.
Refactored the input window handle to separate the properties
(info) and identify (handle) state into different objects.
Then modified the dispatcher to release the properties (info)
when no longer needed, including the input channel.
7. The pointer location overlay does not actually use its
standard input channel, only the monitor input channel.
Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to
request that they not be provided with an input channel
at all.
Improved some of the error handling logic to emit the status
code as part of the exception message.
Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
When we first ported wpa_supplicant 0.8, we had a work around
to fix the supplicant state change behavior from the driver.
Remove the work around since the driver behavior is fixed.
Bug: 5195278
Change-Id: I320f21ab01704931a3def6214b0cc40f214a688e
1. The downTime of the first down event was zero but it should the event time.
2. Hover exit events were not injected while transitioning to delegating
state and when tapping.
3. Differentiation between dragging and delagating state based on
two moving pointer direction and distance is now based only on
the direction. Hence, two pointers moving in the same direction
are dragging, otherwise the event stream is delegated unmodified.
The reason for that is the blind people cannot easily determine
and control the distance between their fingers resulting in
different behavior for gestures which the user thinks are the same
which creates confusion. Also in some cases the delegation and
draggig yield the same result, for example in list view, further
adding to the confusion. This was also causing the status bar to
be opened closed inreliably creating frustration.
4. Refactored the code such that now there is only one method that
injects motion events and all request go through it. Some bugs
were introduced by inconsistent implementation in the different
injection methods.
5. Fixed a couple of event stream inconsistencies reported by the
event consistency verifier.
bug:5224183
bug:5223787
bug:5214829
Change-Id: I16c9be3562ad093017af5b974a41ab525b73453f
selection mode
Fix visibility of menus when action modes are initiailized early.
Fix ListView problems persisting check states.
Change-Id: Idc21036dc39259e72f0e6831a0ccb4695f8858ef
This change moves the Surface ctor that takes a SurfaceTexture to the
portion of the file containing the public APIs.
Change-Id: I192df7bf5c0e6d0d0607bd577d72646312b2f717
Since LockScreen provides its own PIN entry keyboard, we don't need to show
the IME switcher button.
Change-Id: I04528acaee66e5109d631c0c79a3e7c64876e4c5
the screen
Alter preferred options panel gravity policy.
Integrate new menu panel assets for holo apps.
Change-Id: I9fa98ed9359148ea6d1f1d1e727ddcd437b16e2f
Cannot trust references to IRemoteControlDisplay to remain the
same when removing a RemoteControlDisplay, compare the
result of .asBinder() instead.
Change-Id: Ib2e82aa24bd4b12804bccff94a6a0090ff83bea8
The RemoteControlClient / Display feature only supports one
display. If multiple displays are registered, this CL implements
the following policy:
- cannot unregister a display that is not the current one,
- registering a display when another is already registered
causes the old one to be unregistered.
This fixes a death handler leak where the previous display was
simply overwritten, without unlinking to its death.
Change-Id: I63f8a38093796e0960761936d7fc58d47b7589b3
