Bug: 30889568
Fixes an issue where mLayer didn't have
the mSurface set on it in certain resume
scenarios.
Change-Id: Ib75065d3d75e6141d6cd8f306584f6a569b9907c
This type behaves like a normal TYPE_APPLICATION, except that WM
will always wait for it to be drawn before starting a transition.
WM always waits for TYPE_BASE_APPLICATION (main window), but for
TYPE_APPLICATION, it only waits if the window relayouts to visible
and gets a surface before the main window is drawn. If main window
itself is ready very fast, transition could start without the other
window.
bug: 30830849
Change-Id: Ife71a9812db7c8eba6ee4ead10ce4f31d9e93b40
As discussed in ag/1192965/ we have a special case for rotation
animation selection in launch from double tap. This was set to
ROTATION_ANIMATION_CROSSFADE as the goal was just to avoid
ROTATION_ANIMATION_ROTATE on the viewfinder surface and
seamless rotation in launch scenarios was initially descoped. Now we
are aiming at fixing this though, and ROTATION_ANIMATION_CROSSFADE
does not quality for seamless rotation. ROTATION_ANIMATION_JUMPCUT
also would not be a good choice because in the situation that the
rotation occurs before the app starting window appears, then we would
jump cut from unrotated wallpaper to rotated app, I think we want
a crossfade in this scenario. To this end introduce and use a new @hide constant
ROTATION_ANIMATION_SEAMLESS which qualifies for seamless but falls back
to CROSSFADE if seamless can't occur.
Bug: 30171992
Change-Id: If1945b17b5159be4cd5ba0b139d6bea9f7fcca33
In Android N, View#isTemporarilyDetached() returns true if it is called
when the same View instance is handling View#onFinishTemporaryDetach().
Returning true there is, however, sometimes confusing, especially
scenarios like the following case:
@Override
public void onFinishTemporaryDetach() {
doSomeRestoringWorks();
}
private void doSomeRestoringWorks() {
doSomething();
}
private doSomething() {
if (isTemporarilyDetached()) {
// As of N, we hit here if this is called as a result of
// View#onFinishTemporaryDetach().
} else {
// but is the logic here is more likely to be appropriate
// when handling View#onFinishTemporaryDetach()?
}
}
What this CL aims to do is to let View#isTemporarilyDetached() return
false when it is called while handling View#onFinishTemporaryDetach(),
because it should make View#onFinishTemporaryDetach() more useful.
Regarding the app compatibility, View#isTemporarilyDetached() was added
in API 24 hence the impact on this change is still limited.
Bug: 30791718
Change-Id: If384da9f9e6ff849598896901626fd021bae5cda
Call ClipData.prepareToLeaveProcess/prepareToEnterProcess
at appropriate moments to check for StrictMode violations.
Bug: 30772435
Change-Id: I5c84c6c7b3d04094563623156616390d3df6879e
When fetching system services early during boot, if the underlying
binder interface hasn't been published yet, we end up caching a
manager class that is broken for the remainder of the process
lifetime, and innocent downstream callers end up using the broken
cached manager.
Fix this by using an explicit exception to quickly abort manager
creation when the underlying binder is missing. The exception is
only used to skip the remainder of the manager creation, and it
doesn't actually crash the process.
Bug: 28634953
Change-Id: I0cb62261e6d6833660704b93a11185aa11a2ac97
