When animating the pinned stack, we set drag resizing on the top
most task in the stack. This has a couple of issues.
- Only the top most task is put in drag sizing mode and all other
task in the stack will not be in resizing mode.
- The top most task of the stack can change during the animation,
so we fail to clear the drag resize flag on the previous top task.
We now track drag sizing at the stack level and have the stack
drag resizing state affect its tasks drag resizing states.
Also added concept of continuing a bounds animation if the same
target called BoundsAnimationController.animateBounds before the
current animation is done. We don't send onAnimationEnd() for the
current animation that is been cancelled and don't send
onAnimationStarted() for the animation that will be replacing it.
Bug: 25672053
Change-Id: I64e89ed09d81e4802dacebc5818dfa1deb0d588f
The top stack is now removed and the notifications
can scroll below the quick settings header.
Bug: 24866646
Change-Id: Ia480a0efb3ed70a072e0596633063cc0cbbdf1fb
In resumeTopActivityInnerLocked we only update the visibility
if not already visible, to avoid a black flicker. However, in the
interaction when docking a task from recents, makeVisible was
called but the conditions weren't met to make it actually visible,
but Record.visible was still set, leading that we didn't call
WM.setAppVisibility in resumeTopActivityInnerLocked
Bug: 27041808
Change-Id: I400470a5b31881542fedd3edb6a97e524666a8a3
- Make sure divider is pushing frames only if necessary
- When starting recents while docking, make sure no unnecessary
animations are played to reduce system load.
Change-Id: I536f009aef7282ed85dde79b853aeae62644f3e3
- When the window doesn't have a surface, do not add it to
mResizingWindows, so we don't report unnecessary resizes
- computeDragResizing => false when window is not visible, so we
never enter resizing mode even if the window decides to relayout
in the background
Change-Id: I8e6cdef86f1579d128973d4f2f12e87bf9b65524
When relaunching an activity while preserving the window, the content
view was put on top of the status bar background, making it disappear
in case of translucent status bar backgrounds.
Change-Id: I1edff29c10616bf5386e982d7336327135f0f7a0
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
Prior to this change it was relying on NMPS.getNetworkPolicies(), which
would not return networks that never had any policy attribute (like
metered) set.
This change fix this problem by also querying the WifiManager for the
list of saved wi-fi networks. In fact, the new logic is very similar to
what's done on SettingLib's NetworkPolicyEditor.
BUG: 26685616
Change-Id: I42f37de3a7367718036f45b15c6b5d37b67e7d01
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 3cf9fa3db0231d035142c27992818d8f7827ac3e)
+ Camera permission is required for QR provisioning in SetupWizard.
Bug: 26932941
Change-Id: I1573cdd3b8ac708f457a9c7efbbf02c3c8ce6d8d
(cherry picked from commit 950b2dee6648a90bd2e9fedecde137f41f7c4513)
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 7466be66263d5ebffb786ea402d9ed6e36c254f0)
Updates the docs for addNewIncomingCall to mention that if the
PhoneAccountHandle representing a PhoneAccount is not registered or not
enabled, a SecurityException will be thrown (as of b/26864502). Also
notifies the user that PhoneAccounts are stored in DE storage
in registerPhoneAccount.
Bug: 26874536
Bug: 26780305
Change-Id: I2dae932cfa3404d7d5060dad840a75227793603e
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 f6b30662f87f7339d0d3946dcf71e930c2fead9b)
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 759a4c54004af6ac9f42c9c42496a5eb73c461ff)
Add android.os.UpdateEngine and UpdateEngineCallback classes that
communicate with the update engine via binder APIs for A/B update.
Bug: 26695366
Change-Id: I2471858d28df5443bc0b56d9a20281ccebde4484
Showing the pid is useful in many cases, like when one bug report is finished
and another one is in progress.
BUG: 26906985
Change-Id: Ib8ae462c85246b99234f8dac63edb608d1eafeb0
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
Add the means to protect FBE keys with a combination of an auth token
from Gatekeeper, and a hash of the password. Both of these must be
passed to unlock_user_key. Keys are created unprotected, and
change_user_key changes the way they are protected.
Bug: 22950892
Change-Id: Ie13bc6f82059ce941b0e664a5b60355e52b45f30
hotspot, color inversion, data saver, and work profiles should add
themselves when they first become applicable.
Also refactor the availability flow a little bit.
Change-Id: Iaed89059540a98fefd4d26ce69edc0dde987b992
