are canceling the command.
Before it could happen that we have a pending cancel on a layout command
but the layout command finishes normally. This enqueued a new write
command before the PrintActivity is notified. This in turn prevented the
printactivity from finishing as the write command was still pending.
Bug: 27642724
Change-Id: I3c532d53b0c66c40d2e48ab8b4419251ff473a79
Without this fix, rotating the device restarts web browsing
at the first page of captive portal losing any information a
user has already entered.
Bug: 27363244
Change-Id: Ie610f6c7192352eb80acb200d089072cf0197c37
When a notification is being removed by swiping action,
actual removing will be performed after the swiping animation ends.
And also, it is same when removing notifications with <Clear all> button.
The actual removing will be performed after collapsing of status bar.
But before actual removing, the notification flags can be updated
to not clearable, and then the notification view can be remain
out of display by X-translation animation.
Therefore, fix to snap the notification view back when updating
if it is not clearable and need to be come back.
Change-Id: I005a9a8ac82bb513a47b5b8afc430bbe4880b52e
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
Also fixes a bug where the remote input view stays focused
when the inline settings open.
Also prevents sharing from contexts that are not activities,
and prevents text processing when the device is not provisioned.
Bug: 27633360
Change-Id: I8b6e7f661bd873d88e7e2460d043c2aa5f849516
The test launches the DocumentsUI as picker, then waits until the
main thread idles, which guarantees that roots are loaded and UI
rendered.
It confirms, that the recent system cache improves cold start
performance by around 24% on my configuration (from 1685ms to 1357ms).
Bug: 27370274
Change-Id: I738202ea434a7bfe7080fc0994f636ef0e7847cd
If we have an existing file in the destination directory, which has the
same name with the source file, adding suffix number is
DocumentsProvider's responsibility.
Because MTP does not provide a way to check existance of files with
given name, the logic is implemented as try-and error strategy. The CL
lets If we MtpDocumentsProvider assume we have a file that shares the
same name with the source file if it failed to invoke
MtpDevice#sendObjectInfo. In this case MtpDocumentsProvider retry to
invoke sendObjectInfo with new name with suffix number.
BUG=26991190
Change-Id: I223ac5031f079bc91eb27709b0356f621a1ed55b
In this case it cannot call back into the recyclerView and update the
data. For the call path please see the bug.
Bug: 27614499
Change-Id: I84733fea30429c20a2c96085efb47d4da5e1948a
