Previously MtpDocumentsProvider used pipes to transfer bytes from an
application to the provider when writing a document. The problem was
application could not ensure that the last chunk of bytes was
successfully written to MTP device, since pipes had been already closed
when the provider transferred bytes to MTP device. Though the provider
encountered an error, the provider could not report the error to an
application.
The CL switches the method to transfer bytes from pipes to AppFuse. Now
application can flush() bytes on the file descriptor, and flush will not
complete until the provider completes writing bytes to MTP device.
Fixed: 23093747
Change-Id: I4e28f8cbf19d6c97e591943349a7535241d768f7
MtpObjectInfo contains object size as 32-bit integer and the provider
needs to invoke MtpDevice#getObjectSizeLong hidden API to get 64-bit
object size.
The CL switches to use MtpDevice#getObjectSizeLong hidden API if
MtpObjectInfo#getCompressedSize() returns 0xffffffffL, which means the
object size is more than 4GB.
BUG=27805369
Change-Id: I87ea02c09aa784246cf016def309d1f39ed20e90
The MTP spec does not offer a way to update bytes of exisitng files, so
our provider implementation creates a new file with new bytes and
removes old one.
Previously the new file uses new document ID and the exising document ID
is expired. Also the provider does not update the metadata
database. Thus users see the old flie in DocumentsUI but actually the
files is not accessible.
The CL updates the database with exisitng document ID, so that we can
access the new file with exisiting document ID.
BUG=26549400
Change-Id: I629b707a2e662b34625e8b28857ef818d8933996
Uploading was breaking as SendObject request was not being sent directly
after SendObjectInfo which is assumed by the MTP stack in Android.
Change-Id: I36b94f56682e79dec38add9be5f70f55d07e22e7
