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 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
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
Explicitly state that "local state" is local to the window
which has started the drag operation.
Bug: 31372686
Change-Id: Idbea7586c4e74097362067fa90390b97744181bb
Prior to N, if a client received the surfaceDestroyed callback
from their SurfaceView they could trust that the surface would not be
reused. Now that is not true in multiple scenarios. If a client fails
to shut down its EGL context then, we could end up in a situation where,
the client will never disconnect. Then when we reuse the same
underlying IGraphicBufferProducer for surfaceCreated next
the app will crash with a double connect error. There is no valid
use of the surface inbetween surfaceDestroyed and surfaceCreated,
so we just force the disconnection after surfaceDestroyed.
Bug: 30236166
Change-Id: I2e3e4b3176492dc0c2d46a59e0b5a781bf9bc356
mWinFrame as set when returning from relayout will be in screen
space coordinates. repositionChild however expects coordinates relative to the
parent position (like relayout).
Bug: 31112993
Change-Id: Id4fcd7fcb771908e8a7db981207d19c99fb51b98
