Prior to this commit in this case of activity pause, with finishing=true
the activity manager will notify us of app visibility and we will begin
an exit animation. When this exit animation finishes, we will destroy
the application surface (unless its eligible for saving). However there
are two cases where this breaks down:
1. The exit animation finishes before the activity thread handles
the stop transition. Many activities stop rendering on Pause
but many do not and it is totally legal to do so. Sometimes this
results in non fatal dequeue buffer errors and sometimes results in
fatal errors with Pixel Buffers, etc...
2. We may resume the activity shortly after asking the window manager
to pause it. If the window wasn't eligible for animation, we will
immediately destroy it after being told of the visibility change
following PAUSE_FINISHING. It's possible for this to complete
before we process the resume. On the other hand the client
happilly processes the resume and transitions back from PAUSE
and then crashes once it attempts to use it's surface.
In this commit we have the activity manager notify the window manager
when an application has actually finished (or we have timed out
waiting). For windows which have not been explicitly removed by the
client, we defer destruction until we have received both this signal
and the animation has completed.
Bug: 26793431
Change-Id: Ib6ee8fbdd1f03450fbbfd62468a19e97774befab
Bug 26963113
When a Fade transition is interrupted and reversed, the
View started the animation from the beginning. This change
captures the previous transitionAlpha and starts the animation
from the previous alpha state.
Change-Id: I801fe9ade6af4cf8446838e231bdc71841668a18
(cherry picked from commit 3cf9fa3db0)
We confirmed with the graphics and JIT teams that no sensitive
user data is written to these caches, so they're safe to point at DE
storage.
Since we don't have control over what is written by the app, we need
to keep the cache environment variable pointing at CE storage.
Fix ensurePrivateDirExists() to always return a path, instead of
returning null which can cause scary bugs.
Change packages.list to no longer canonicalize data paths, since
these fail when CE storage is still locked.
Bug: 27069522
Change-Id: Ifff64a036fa4aa1e61aa0dd98486bc711fbf8f4a
Save arbitrarily nested fragments across config changes as
nonconfiguration objects. This permits the use of retain-instance
child fragments as arbitrary opaque dependencies within other
fragments.
Change-Id: Ia6640b76cfcf7ec28ba252628957a0c14863e957
(cherry picked from commit 7466be6626)
Offer commitNow and commitNowAllowingStateLoss methods on Fragment for
use by encapsulated components using fragments as implementation
details. This can help prevent unexpected ordering side effects at the
app level when a call to a library method wants to commit and
immediately initialize a fragment as an implementation detail.
Note that this change still does not permit reentrant FragmentManager
operations. It is still an error to add/remove/change fragments in the
same FragmentManager while a fragment transaction is being executed.
Have the commonly used ViewPager adapters use commitNow instead of
executePendingTransactions.
Change-Id: Ia37a871234a287423063f0c2c3e4c93d69116cad
(cherry picked from commit f6b30662f8)
Have the new showContextMenuForChild(View, float, float) call through
to the old showContextMenuForChild(View) before recursing up to its
parent. This ensures that existing apps with custom views that
override the old method still get called as expected if they implement
custom behavior.
Unlike some other similar circumstances we aren't implementing this to
be bidirectional as the new behavior doesn't need to be triggered by
invoking the old. If the older method is invoked explicitly we will
still show old-style dialog context menus instead of the newer popup
style since we won't have a good place to visually anchor a popup.
Bug 26919262
Change-Id: Ie09f922d322b5a24789c7867820c4bc43824c385
(cherry picked from commit 759a4c5400)
The general theme of these changes is to always delay any action until
the printDocument finishes a command. This is done:
- Before callinng for into a different activity to select a name for the
PDF
- Before finishing
The second theme is to fix the canceling behavior of
RemotePrintDocument.AsyncCommand.
There are four bugs fixed in this review:
(1)
When the RemotePrintDocument.AsyncCommand is canceled it goes into the
"canceling" state. When it is canceled again it should stay in this
state. Before it went to "canceled" but the command was still running.
(see AsyncCommand#cancel()).
(2)
When finishing the PrintActivity in PrintActivity.doFinish() we cancel
the RemotePrintDocument. If there is a command still in progress (i.e.
isUpdating()) and it finished as canceled we used to call doFinish()
again and then try to double-clean up which lead to exceptions.
The new behavior is that is the PrintActivity is calling doFinish()
while a command is still in progress (i.e. isUpdating()) we delay the
cleanup until the command finishes. The command might finish as
canceled, completed or failed. Hence we have to call doFinish() in the
callbacks for all three cases.
(3)
When canceling there might have still been a nextCommand ready, hence
canceling does not stop execution of the RemotePrintDocument which could
lead to running commands while finshing.
(4)
When getting the location to store the PDF at a command might still be
in progress. This lead to half executed commands and caused issues once
we try to continue after the select-location-activity returns
Bug: 24713704
Bug: 24973884
Change-Id: Ied90fe8dc9bd6ea7f8b3e4ce4f922e477015568d
