This change saves and loads a different brightness setting when the user
goes in and out of VR Mode.
Bug: 30984614
Change-Id: If3c3e81b592e0c6fd037e5783559683e5cb58379
This change saves and loads a different brightness setting when the user
goes in and out of VR Mode.
Bug: 30984614
Merged-In: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93
Change-Id: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93
Swipe to dismiss on dialogs did not dispatch onCancel events
to OnCancelListeners. Resolve by adding listener to monitor
swipe to dismiss events and dispatch onCancel events when
that occurs.
Bug: 33663411
Change-Id: I64ff29e008d485a4559eb3d1ff7f0e74dccff404
Also adding same robustness to interrupt that we have for
sending a11y events.
Bug: 32507871
Test: Ran a11y CTS. Verified manually with sample app
that sends interrupt and accessibility service that
crashes when started. That case used to crash the
app, and doesn't anymore.
Change-Id: I5cf05dcbb54ea23ae876cb3258dd206c55dce775
(cherry picked from commit 867ad35d9c)
Instead of relying on the window animation system, in the special
case of a swipe-dismiss, disable any default window exit animation
and perform a custom animation. This bypasses some bugs in the
window animator codebase and allows us to have a nice "rebound"
animation if the user doesn't swipe far/fast enough to trigger a
dismiss.
Bug: 33041168
Change-Id: Ied45700d35a59950bacef1ba0650eaa5bc60fadb
Test: docs only, no test apart from verifying that it builds
Bug: #32158219 clean up InputConnection.commitContent() javadocs
Change-Id: I9b438d6b14aa8bc868fe41f7e0fe22b0e83800fb
This CL reflects the N MR1 behavior and
fixes some bugs.
Defining the compatibility behavior will be
done separately.
Bug: 31702571
Change-Id: I2a79871f47849f9f5a9c3377a3061208488e6ecb
- 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
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
Explicitly state that "local state" is local to the window
which has started the drag operation.
Bug: 31372686
Change-Id: Idbea7586c4e74097362067fa90390b97744181bb
