We have added device name to storage root by ag/790395.
But the change was not added to MtpDatabase class.
BUG=25162822
Change-Id: I019a9cf770a91c43b4e2f4e81e74b40175fd4872
If the remote MTP device is backed by typical file system, the file name
is unique among files in a directory. However, MTP protocol itself does
not guarantee the uniqueness of name so we cannot use fullpath as ID.
Instead of fullpath, we use artifical ID generated by MtpDatabase
itself. So we don't need to store fullpath in the database.
BUG=25162822
Change-Id: I06598ce631a3221ed72e11734dbdaefef4c6349c
When app is paused, keep the window surface around. Use it to start
enter animation if size remains unchanged on next launch.
bug: 19940527
Change-Id: Icf88d81f08b59e8bd946e410611f5098b253eb10
We had three different sources of information about where the
animated window will start/end: appFrame, containingFrame,
containingWidth/Height. We can merge these into one, because
containingWidth/Height can be calculated from containingFrame and
appFrame is actually used only once and the containingFrame is not
used in the same scenario.
Also, documentation about the frames and insets. The rest is fairly
simple, but frames and insets need explanation of how they are used.
Finally, simplify naming.
Bug: 25246833
Change-Id: I0accc2f23792bca4e1b9941007c6249745e023ce
We need to be more precise when removing the window that is being
replaced. We used to depend on the fact that we can remove it after
the first draw of the new added window. However, due to resizing the
old window might reset its draw state and that will trigger a removal
of that window.
We need to add an information about the window that is replacing the
old one and only when this new window draws itself, we remove the old
one.
This improves the transition after maximizing docked window. This is
a situation where first resize operation finishes and immediately
after we have a replacement operation.
Bug: 24914011
Change-Id: Ia8e5bb7872787e663ba23f26588f9c4db1a5e574
It was not aligned, because we didn't take into account that the
docked window will be cropped by the status bar and navigation
bar. We need to account for that when creating the animation.
Bug: 24913915
Change-Id: Idb82eefa14d65fe3bf6b25a9bd94c12dc8cbe648
* changes:
Support for activity to opt-in/out of PiP form of multi-window.
API for moving top activity in a stack to pinned stack.
Added support for pinned stack.
While it makes sense to be able to resize most activities types
in multi-window mode. It only makes sense to put specific types
of activities in Picture-in-Picture (PiP) form of multi-window.
For example, activities that play video will be good candidates
while the Settings activity isn't.
The new flag allows the system to differentiate between resizeable
activities that can go into PiP mode and those that can't.
Bug: 25006507
Change-Id: I8ac518cec2fa3c8fb88be40c266b3751fb88f1ce