- 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 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
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
It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout.
Now for apps targeting SDK greater than N MR1 to add a
toast window one needs to have a special token. The token
is added by the notificatoion manager service only for
the lifetime of the shown toast and is then removed
including all windows associated with this token. This
prevents apps to add arbitrary toast windows.
Since legacy apps may rely on the ability to directly
add toasts we mitigate by allowing these apps to still
add such windows for unlimited duration if this app is
the currently focused one, i.e. the user interacts with
it then it can overlay itself, otherwise we make sure
these toast windows are removed after a timeout like
a toast would be.
We don't allow more that one toast window per UID being
added at a time which prevents 1) legacy apps to put the
same toast after a timeout to go around our new policy
of hiding toasts after a while; 2) modern apps to reuse
the passed token to add more than one window; Note that
the notification manager shows toasts one at a time.
bug:30150688
Change-Id: Ia1dae626bd9e22541be46edb072aa288eb1ae414
This CL fixes typos in JavaDoc for InputConnection.
This CL slso updates the content regarding a new API that was added in
API 25 [1][2].
[1]: Iaadf934a997ffcd6000a516cc3c1873db56e60ad
152944f490
[2]: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
adebb52588
Bug: 31249896
Change-Id: Icafedb15943a84f8e5b03ef9eb3a50627d508bdd
TalkBack was speaking all Toasts twice because we were
sending both NOTIFICATION and a WINDOW_STATE_CHANGE events
when Toasts were displayed.
Stop sending the WINDOW_STATE_CHANGE event for toasts.
Bug: 30570188
Change-Id: I26c6dc50350dfd4daf2a706b94fadcf5d1e03557
Surface is parcelled partly in java, partly in native, and any fields
added in java have to be accounted for in the native side as well.
Add a warning to avoid issues in the future
Bug: 31162160
Change-Id: I48ca1bc3eea29f1ac3d3065f6defb6ed2be4052a
The following changes are in this commit:
Avoid destroying TextureView surfaces for onStop
bug:30238922
TextureViews will hold onto their backing surfaces, which will allow
them to resume gracefully when the app's surfaces are saved.
Now only resources that are destroyed for onStop are DisplayLists.
(cherry picked from commit 391d560402)
TextureView: destroy layer on destroyHardwareResources event
bug:30468770
(cherry picked from commit 1c16c37d86)
Fix NPE in TextureView
Bug: 30651595
(cherry picked from commit 3c2587f26e)
Fix NPE in TextureView
Bug: 30779663
(cherry picked from commit 7e237189c2)
Fix maps resume being blank
Bug: 30889568
Fixes an issue where mLayer didn't have
the mSurface set on it in certain resume
scenarios.
(cherry picked from commit 03df0834e6)
Before there was a jump-cut when a window that was occluding Keyguard
was going away, leading to an ugly flicker. To fix this, we do the
following.
- Always show windows with FLAG_SHOW_WHEN_LOCKED above lockscreen, even
if they don't "match" the currently occluding app (which is null in the
animation case)
- Move wallpaper behind last window that is not hidden by policy, so the
window doesn't get occluded by the wallpaper.
- Add a flag in the setOccluded call whether to animate or not. SystemUI
then plays a nice animation when it's set.
- Override the animation to always be the animation that happens when we
exit a window which is revealing the wallpaper behind, to make it
consistent with the home screen case.
Fixes: 30829255
Change-Id: Ib3fe20fc9003a0f9f291c974740f044ed8707e75
This CL fixes an edge case that my previous CL [1] forgot to handle.
The goal of my previous CL was to avoid InputMethodManager from getting
confused by a false focus-in event from temporarily detached Views.
However, my CL forgot to take care of the case where the temporarily
detached View is still focused even after the temporary detach mode is
done.
The bad news is that such a situation is relatively easy to trigger by
having a ListView that has EditText as follows, which seems to be
known to be a common technique in Android developer community to put an
EditText in a ListView.
ListView#listView.addHeaderView(new EditText(context), null, true);
If the ListView is initialized as above, and the EditText has input
focus, View focus and IME focus start to disagree immediatelly after the
ListView's layout is re-evaluated. This is really easy to trigger, for
example just by dismissing the IME window.
In summary, the root cause is that InputMethodManager#focusIn(View) is
now always ignored as long as the View is temporarily detached, under an
assumption that IMM#focusIn(View) will be called back again with a View
that is not temporarily detached when everything is stable. Hence the
fix is to do so by hooking up View#dispatchFinishTemporaryDetach() to
call IMM#focusIn(View) again when the View is actually focused in the
final state.
[1]: Ia79bbd8468f768d546354382b47b39dd31ef7bb5
a4ed0cfcb6
Bug: 30022872
Bug: 30578745
Bug: 30706985
Change-Id: Iecbdb00dcef8c72e4f7b31035c9bf0f4a40a578f
(cherry picked from commit dd228fbb4d)
