Code search show nobody referenced it and aosp image still compiles after
remove it.
Test: make -j18 systemimage userdataimage ramdisk
Change-Id: I3e37ea590610091b938296c999dceb3caf919906
Merged-In: I3e37ea590610091b938296c999dceb3caf919906
Signed-off-by: Tao Wu <lepton@google.com>
This CL reflects the N MR1 behavior and
fixes some bugs.
Defining the compatibility behavior will be
done separately.
Bug: 31702571
Change-Id: I2a79871f47849f9f5a9c3377a3061208488e6ecb
If setView() will be called from two different threads
then mView property of a View object may have inconsistent
value. For instance, setView() may set mView to null causing
NullPointerException. Synchronize root.setView() as well to
avoid this.
Change-Id: I5f9cf47ece5d4aca575bd8644ecfcee0ed43d843
- Prevent third party apps from inadvertently changing internal SystemUI
flags through a call to setSystemUiVisibility(). These flags are only
set in the individual SystemUI components and can be updated in WMS
directly.
Bug: 29875297
Change-Id: I5ea238c8fb16a0eccd6e993d95a912acb359cee6
To restore the pre-N behavior, if a view returns false from its
LOCATION or DROP event handler, the event goes to its parent.
Bug: 31559942
Change-Id: I322099ae1e8a5cbbcf8814f2cd274fbae53b6848
Fix issue #30766518: Document what targeting N does
Also small documentation cleanup in a few other places.
(cherry picked from commit b34cbedb4e)
Change-Id: I9560b29faa4f2674277349272af8193122a1f95e
The onKeyMultiple() event captures simulated, not actual, presses of
the same key in rapid succession. Adjusted the method definition to
include this clarification.
Bug: 2335983
Change-Id: Id01182d81dafe98df9e559ff24f9e1d5a1f949c3
The bug complains that parents of a view under the drag location
don’t get drag events.
This is first of a 2 CLs that will restore the old functionality
(modulus fixing bugs) for pre-N apps.
This CL restores pre-N "nested" model of the entered state for
pre-N apps. It also makes possible restoring "nested" model for
LOCATION and DROP (implemented in a follow-up CL)
The CL replaces (for pre-N) generation of ENTER/EXIT events that
happens at the moment of changing the drag focus with generation
folowing the recursive delivery of coordinate-bearing events.
Bug: 31559942
Change-Id: Iead6bde9c1f88819b30afc78c1f424f7c1b64d51
This causes frequent programming errors, when developers assume
that holding onto a Surface will keep its associated SurfaceTexture,
ImageReader, etc, also alive.
Bug: 31551063
Test: m offline-sdk-docs, manual viewing of result
Change-Id: I5fb5bb3e3c80c7d5d735417b1697e0fe9a62fc46
Currently, a container view that doesn’t accept events, but has a
child that accepts events, prevents its parent from receiving
LOCATION/DROP events while the drag is over the container (but not
the child). This is a bug.
With this fix, such a container will prevent the parent from
invoking a (second) LOCATION/DROP event only if the event was really
delivered to any of its descendants.
To know whether the event was delivered, I added
DragEvent.mEventHandlerWasCalled member.
EXITED/ENTERED events are now generated upon delivery of the event
that has coordinates in it.
Current view that has drag focus is now global to reflect the fact
that it’s one per process.
Bug: 31469490
Change-Id: I248e8d1de87b7734853136eb4719f7571cea91d5
getCurrentInputMethodSubtype() acquires InputManagerService.mMethodMap
within its body. There seems to be no reason for holding
InputMethodManager.mH to call getCurrentInputMethodSubtype(). Holding mH
can cause potential deadlock b/w two threads acquiring mH and mMethodMap
in different orders.
Bug: 31247871
Bug: 31273203
Bug: b.android.com/218423
Change-Id: I20cf2c20f49b1b02c0f7a18257b49d4bcc081b5d
