Add code to adjustWindowLw to force the flag
FLAG_NOT_FOCUSABLE to be set for layer type
TYPE_SCREENSHOT.
Bug: 30485483
Change-Id: I11725eb89fda59b6d50fa1700845cdfe9ffb930b
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
- Adds a trusted signal from Keyguard to PhoneWindowManager
- Allows PhoneWindowManager to exempt DISMISS_KEYGUARD windows from force hiding
- Allows PhoneWindowManager to dismiss Keyguard while occluded
Bug: 27410215
Change-Id: I3ad490b64a5805b6f3888a9f37fcfbdd0116395e
Prior to N, our widgets were not converting MarginLayoutParams
properly between ViewGroups. The fix intrudced some issues in
older apps as the broken conversion code would hide developer
errors. This CL guards the change with a target API check so
that we don't affect older apps.
Bug: 30378230
Change-Id: I215281d261b553c3b4cedcd29ea0a861df809471
Bug: 30587465
Someday maybe the technology will exist to
allow sharing a simple constant between
Java and C++, but today is not that day.
Change-Id: I17694746cb8712058133cd5ea10c47b9909f740b
Changes in alpha only matter if they affect visibility,
so only 0 <-> nonzero changes are worth reporting. Report
them as subtree changes, as visibility affects subviews.
Not reporting every change greatly reduces the number of
event reported when alpha is animated.
Bug: 30183085
Change-Id: I905d53aa81ca8248b3aed86a91842ef499f303a8
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: Icc8f8dbd060762ae1a7b1720e96c5afdb8aff3fd
This change is needed to correctly cope eg. with list views
which introduce header and footer view through additional
list view padding.
See ag/1221005 for details.
Bug:30420573
Change-Id: I7c9c0ce2b5ba85429b7921c42e4f97e139814e17
Fixes a bug where the sysui visibility flags
were not dispatched when they changed if the
visibility changes the first time to a zero
value.
Change-Id: I4d6c990ca493b144f24c75e95b4ff18c4c0a029c
Fixes: 30259249
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.
Change-Id: Ia768ba9ffc4497c26aa3a5b101a0f5fa1a258b9c
When quickly toggling between two apps, app could be resumed while
it's stopping but not yet stopped. Upon resuming, it could have
surfaces that's marked mDestroying and waiting for the stopped
to be destroyed.
We need to dispose these surfaces properly. If the window is already
removed, we destroy them. Otherwise, clear mDestroying flag so that
the window is ready to be used again. Leaving mDestroying=true makes
the window ineligible for certain things such as receiving wallpaper.
bug: 30255354
Change-Id: Id881653550595ab8e702d6950949bf202ac5a0d9
Provide a way for views to signal that they would prefer not
to have their parents scroll or otherwise rearrange when they
request focus to try to show the full focused view to the user.
In some cases this can be disruptive to the UX.
As of now, framework views do not respect this hint and custom
views such as those found in currently deployed support libs
don't either. The policy is left open to ViewParent subclasses
that implement requestChildFocus.
Bug 30256922
Change-Id: I55194de888fe2b8129be9a9aa21aa5e18cbb8296
Apps are told to query AccessibilityManager#isEnabled before
calling sendAccessibilityEvent. If accessibility is disabled
between the two calls, an app can crash. We can guarantee that
this won't happen on a process's main thread, but guaranteeing
it for all threads is messier. Rather than add the complexity
of tracking the state for all threads, only log an error in the
corner case that an accessibility event is requested on a
thread that doesn't have the process's main looper.
Bug: 28985452
Change-Id: I8369deefd83b0a6b04936ddfce55c53147756f1f
Also, standardize on a set of possible modes for the displays to
enter and separate the configuration of the color mode from the
configuration of the display mode.
Bug: 29044347
Change-Id: I6af0a7d1f11bc72d4cefc380f115c1fb00788864
In some corner cases, ViewRootImpl#setAccessibilityFocus
can be called twice for the same view. Make sure we're
actually changing views before clearing accessibility focus
to avoid inconsistent state.
Bug: 29637593
Change-Id: I5dc6f05bdeaec55c352417bfca92c11bd03c3c10
(cherry picked from commit da4692774c)
Alternative fix for b/29391054 ag/1152795 sends an MOVE message to
client which also force a layout, so we no longer need to force
it after the insets change in the traversal.
Reverting the following two related fixes as it does more
measures than necessary.
bug: 29391054
bug: 29533997
bug: 29634368
Revert "Fix layout issue after insets changed"
This reverts commit 76fdbb72c9.
Revert "Do a forceLayout if pending insets is changed after relayout window"
This reverts commit 71f2c31469.
Since they're recorded as floats, we should keep the
precision from the attribute values.
BUG: 30109000
Change-Id: I07e6a3ff771198bcb24d32e3dd06a79f10e51a7e
Document that getClipDescription() and getLocaState() do not return valid data
when getAction() == DragEvent.ACTION_DRAG_ENDED.
Bug: 30016099
Change-Id: Id98fe8c5d6f052fc51c8c9e8d55329e162bd96b1
Add a new mode, controlled by sys.use_fifo_ui property, that enables the
top app's UI and RenderThread to be SCHED_FIFO. This eliminates almost
all jank due to scheduling competition with non-UI critical
threads. This mode may not be suitable for all devices.
bug 24503801
Change-Id: I7b8a31830ad80f7efa00236928d5476998ed4e00
