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
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
Some apps rely on their drawables not getting not-visible hints via
setVisible when the window visibility changes. This manifests as
additional animations, such as crossfading from placeholders when the
window becomes visible again.
Apps should be able to handle this case in the future now that we have
more detailed reporting via onVisibilityAggregated, but to keep
existing apps working as-is, ImageView now operates in a compatibility
mode for targetSdkVersion < N and will only dispatch visibility
signals based on the same triggers used in M. New apps get the more
detailed signals.
Fix a bug where window visibility dispatch via onVisibilityAggregated
would double-dispatch "not visible" when the window is transitioning
from GONE => INVISIBLE or INVISIBLE => GONE.
Make the growing set of compatibility check fields in ImageView
static, matching the pattern from View.
Bug 30216207
Change-Id: I88875260bf6aaa23687c7d51353de8d633383531
Restrict saved surface to launcher start (ACTION_MAIN&CATEGORY_
LAUNCHER), or there is no intent at all (eg. task being brought to
front). If the intent is something else, likely the app is going
to show some specific page or view, instead of what's left last time.
This solves problems like the launcher shortcuts on DeckClock,
each of them is a different intent and will show one specific
view regardless of last states. Another example is Chrome tab
opened directly by action VIEW to open some URL.
(Note that this doesn't solve the problem with Chrome homescreen
shortcuts, it will still start with saved surface (if Chrome
is already open). This is because the shortcut is a trampoline
activity that starts the real chrome tab activity, but when
the trampoline is started, the whole task is already brought
to front, and ChromeTab could become visible with the task
before we actually start it.)
bug: 31055479
bug: 27747315
Change-Id: Id3e61c61ef516b0edc1f174320f02661222f226b
(cherry picked from commit ad24f96def)
This reverts commit c34649411d.
Dispatching accessibility events in their own thread is causing Chrome and gmail to crash. We've identified two issues: Chrome is allocating strings natively using references that aren't valid outside of their thread, and the text is being set to values that are changed in the UI thread.
I'm going to resolve these issues on master by making deep copies of the strings, but that change will have its own performance implications.
Since we were bit almost immediately by an unexpected result of this change, and I need to erode its benefit by making deep copies, I think it's a bad bet to push it into MR1.
Bug: 31042124
Change-Id: I6f5c225a9197036db43fd0ac6008447b22617525
Some existing apps treat drawable visibility notifications as a signal
to crossfade from a placeholder to the new image for the purposes of
scrolling onscreen via a recycling collection view or similar. Since
dispatchVisibilityAggregated is now called for window visibility
changes and ImageView informs its drawable of the visiblity change,
the extra call triggers a repeat fade-in in some existing apps when
you return them to visibility.
These apps should pay attention to the second parameter of
Drawable#setVisible, which signals that animations should not restart
in response to a visibility change. Updating to targetSdkVersion=24+
will enable the new behavior.
Bug 30216207
Change-Id: I27ce9f09bc7544863f7f7980c273650949db21cc
This value is used to convert ACTION_SCROLL axis values into raw
pixel distances.
CP of ag/1333603 from master to feldspar-dev. New method is @hide and
@SystemApi in this version. In master, it's part of the new public
API, but feldspar will launch before O.
Change-Id: I5ee73ebcd183c43939ae8aa157e88489e05d4760
First, we fix the transparent region computation to use the order as the
drawing. Previously, it is using the tree traverse order, not the draw order.
Second, add the y offset for any view with positive z value, this will allow
some space for shadow.
b/30124573
Change-Id: I98d38261ffd346b762651e087cb243e45fed6952
Bug: 30889568
Fixes an issue where mLayer didn't have
the mSurface set on it in certain resume
scenarios.
Change-Id: Ib75065d3d75e6141d6cd8f306584f6a569b9907c
