MtpDevice::sendObject is using int to define object size,
if the object size is bigger than 2GB, the size will be type-cast to
a negative number. And it will cause a endless loop in MtpDataPacket::write
until DUT auto reboot.
And JNI api android_mtp_MtpDevice_send_object requires that object
size must be uint32_t , so MtpDevice::sendObject works well after its
size parameter is changed from int to uint32_t.
Also change the return type of below API from int to int64_5
int64_t MtpDataPacket::write(struct usb_request *request, UrbPacketDivisionMode divisionMode,
int fd, size_t size)
so that it can return the right size in the case of writing 2~4G file.
Test: manual - connect Android device to Android Automotive
Test: manual - select MTP/File Transfer in android device
Test: manual - copy a file which is bigger than 2GB from automotive to the android device.
bug: 115451170
Change-Id: I65b89f195ef0527a802bccefc90721e536683b87
Signed-off-by: robinz1x <robinx.zhang@intel.com>
Signed-off-by: Guobin Zhang <guobin.zhang@intel.com>
Linux uses UTF8 but java and MTP both
use UTF16. In a few places, this results
in the top byte of a UTF16 string being
truncated on conversion to UTF8.
Also, the hardcoded UTF to byte serialization
in MtpStringBuffer is incorrect.
Replace it with conversions from std, and
replace usages of MtpString with MtpStringBuffer.
Remove any remaining usages of libutils
and replace them with corresponding std
libraries.
Bug: 70546563
Test: Mtp works, tests pass
Test: file/folder names containing emoji can be transferred to/from
windows
Change-Id: Idbcb73f1beac17ce8a90843fa254e759dd1a6369
This fixes a warning: Access to field 'mPlaybackFormats' results
in a dereference of a null pointer (loaded from field 'mDeviceInfo')
[clang-analyzer-core.NullDereference]
Bug: None
Test: Static analyzer no longer complains, bullhead still boots with no
apparent issues.
Change-Id: I71ce486c667441d9b90ef63c2df8d23d70254639
When sending a MtpDataPacket to a MTP device, the kernel driver splits
it into multiple URB packets so that the URB packet size does not exceed
the buffer size at the MTP device.
Previously MtpDataPacket sends its header first, then sends the
payload. It means the first URB packet only contains the header of
MtpDataPacket and the URB packet size is smaller than the maximum URB
packet size (short packet). Some MTP devices regard the short packet as
the end of the sequencail URB packets, thus the devices do not accept
the following URB packets that contain the payload.
The MTP spec says if the responder (MTP device) sends the data in a way
where the first pacekt contains only the header, the initiator (MTP
host) must send data in the same way. Otherwise the initiator must not
send a short packet in the sequencial URB packets.
The CL fixes the MTP host implementation so that it remembers how the
MTP device sends data, and uses the same way when sending data
from the host.
Bug: 31165557
Test: Manually invokes MtpDevice#sendObject
Change-Id: Ic76eb4241ed74957414aef2990be08cd77a9f5a9
(cherry picked from commit d4b4296b40)
According to the MTP spec, the sendObject request must follow
sendObjectInfo request and we could not send an object handle with
sendObject request. The CL stops sending object handle with a sendObject
request. Instead it checks if the given object handle equals to the
object handle returned by the previous sendObjectInfo request.
Bug: 31918048
Test: manually invoked sendObjectInfo and sendObject.
Change-Id: I0a80bdf67bf2913522821ac705f3dc548d3edead
(cherry picked from commit 8d20945c08)
When sending a MtpDataPacket to a MTP device, the kernel driver splits
it into multiple URB packets so that the URB packet size does not exceed
the buffer size at the MTP device.
Previously MtpDataPacket sends its header first, then sends the
payload. It means the first URB packet only contains the header of
MtpDataPacket and the URB packet size is smaller than the maximum URB
packet size (short packet). Some MTP devices regard the short packet as
the end of the sequencail URB packets, thus the devices do not accept
the following URB packets that contain the payload.
The MTP spec says if the responder (MTP device) sends the data in a way
where the first pacekt contains only the header, the initiator (MTP
host) must send data in the same way. Otherwise the initiator must not
send a short packet in the sequencial URB packets.
The CL fixes the MTP host implementation so that it remembers how the
MTP device sends data, and uses the same way when sending data
from the host.
Bug: 31165557
Test: Manually invokes MtpDevice#sendObject
Change-Id: Ic76eb4241ed74957414aef2990be08cd77a9f5a9
According to the MTP spec, the sendObject request must follow
sendObjectInfo request and we could not send an object handle with
sendObject request. The CL stops sending object handle with a sendObject
request. Instead it checks if the given object handle equals to the
object handle returned by the previous sendObjectInfo request.
Bug: 31918048
Test: manually invoked sendObjectInfo and sendObject.
Change-Id: I0a80bdf67bf2913522821ac705f3dc548d3edead
In the MTP spec, the object size is stored in MtpObjectInfo as unsigned
32-bit integer and fetched by the getObjectInfo operation. For the
objects that are more than 4GB, the object size is provided as one of
extra properties, which are fetched by different operation.
The CL adds to getObjectPropValue method to MtpDevice class so that
client code can obtain 4GB+ object size from object property.
BUG=27805369
Change-Id: I0b91facd07cdc19866cb29f7df08bb1698bcf60b
The CL removes redundant check for containter type. We have the same
check just after the removed check, but the removed check returns
opposite value for boolean result of the function.
BUG=27805514
Change-Id: Ia8e32c0c38553a9a0ec4d9d726b8cde6281d34e1
usb_device_claim_interface is called solely for marking that a program
or a driver uses it and it does not trigger any signals over the bus.
usb_device_claim_interface has a possibility to be failed if the kernel
driver already connected to a usb device. When it happens, the function
call returns an error and errno is set to EBUSY. For that case, it is
necessary to disconnect to the kernel driver and retry to claim the
interface again.
Bug: 26845384
Change-Id: I4fae0e66ca1132f8cc16937cc6fb837ec4d5659f
The CL was previously reviewed at ag/842911.
> The CL makes MtpDevice#reapEvent return event parameters as well as
> event code.
>
> BUG=26480986
Change-Id: Ie750a58248068cd0e804f20b57e7e86eef19d315
If a requested object is 0 bytes, the remote MTP device can return
MTP_CONTAINER_TYPE_RESPONSE at the first response package. Previous
implementation does not handle the case.
BUG=26317907
Change-Id: I6ae1138bf1b24aa197575bea0440cc032ffd622a
The comment says it skips the interface that does not have MTP or PTP
interface class, but previously it accepts such interfaces.
BUG=25960704
Change-Id: Idba07d4c6432d73cf45d9a3422af0ad18cd1b280
Two issues are resolved:
- sendObject changed to accept raw arguments instead of objectinfo,
as calling getObjectInfo after sentObjectInfo is illegal,
- send buffer decreased to 16K, as this is the maximum size working
per comments in other places.
Change-Id: If71644dcbc508dd92c3fe74a2fdb7c6798059b42
Previously the two functions have separate but similar implementation. ag/750097
fixed a bug in importFile, but we have a same bug in getObject. Instead fixing
the bug separately, the CL adds a common function that can be used from both
getObject and importFile.
BUG=23264575
Change-Id: I0bdc876ee9b11301ba4c445cc16556e9c951a8b4
Once the object bytes is requested on the MTP client device, the device tries to
send whole data of object. We need to read the complete data from the device
even when we have errors at the destination file descriptor. Otherwise the
object data will be received as a response of next request unintentionally.
BUG=23264575
Change-Id: I3369786370022f65aa760dd6b75204a946f712af
This CL fixes three bugs:
1. Wrong condition, which caused MtpDevice::sendData always return false.
2. Sending data separately was incompatible with the server side, causing
receiving only partial data on the server side.
3. Sending uninitialized buffers (sic!) from MtpDevice::sendObjectInfo
due to missing call to reset().
4. Sending corrupted packets from MtpDevice::sendObjectInfo (shifted by
4 bytes) due to missing reset().
5. Sending incorrect parent in MtpDevice::sendObjectInfo in case of not
specified parent.
Change-Id: Ia545c66b388ea9a292ba31f6ff034e2467037d92
This will allow to read files on Java side without copying all bytes to
memory first, which is problematic for large files such as movies.
Bug:22908937
Change-Id: I67b116cf01d9e44af69f94c8edc64fd8fbf7b9a3
Previously we did not sanity check incoming MTP packets,
which could result in crashes due to reading off the edge of a packet.
Now all MTP packet getter functions return a boolean result
(true for OK, false for reading off the edge of the packet)
and we now return errors for malformed packets.
Bug: 18113092
Change-Id: Ic7623ee96f00652bdfb4f66acb16a93db5a1c105
MTP initor in Android only support MTP responder based on USB2.
Add support for MTP device based on USB3.
Change-Id: I52b7a5ddff8ae3f8c2ce8a802c2cb2865f4e162a
Signed-off-by: Bo Huang <bo.b.huang@intel.com>
- change internal sized types to use stdint.h
- printf & scanf formats
- size_t or unsigned int for iterators
Change-Id: Id993a70d8bf54c667c5d652b34179a2c727ed446
When creating a new file using open(..., O_CREAT), it is an error
to fail to specify a creation mode. If a mode is not specified, a
random stack provided value is used as the "mode".
This will become a compile error in a future Android change.
Change-Id: I36a3d67d294a915c1f79632a1b0ba45edd1214b1
This replaces the previous ContentProvider based interface
Change-Id: I4cea2544854adb9fdcc04345e4d73d8ef05380f3
Signed-off-by: Mike Lockwood <lockwood@android.com>
This will happen if the device needs to report an error rather than returning the data.
Change-Id: I477512b3676c2f0518a85a4135832ed4475fbc2d
Signed-off-by: Mike Lockwood <lockwood@android.com>
Now the file copy is done completely within the media process
rather than pushing data to the client via ContProvider.openFile().
File system writes are now interleaved with USB reads, which allows us
to copy the data faster and prevents the camera from timing out during transfer.
File is automatically inserted in the media provider after a successful import
and a Uri is returned to the client.
BUG: 2994234
Change-Id: Ie75c63da76f623343d3d966c6a707aa1ae871972
Signed-off-by: Mike Lockwood <lockwood@android.com>
Added support for the "device friendly name" and "synchonization partner"
properties, which are required by Microsoft.
Change-Id: Ic0443333d75f7d98a2d902a790b9d505a56d4eef
Signed-off-by: Mike Lockwood <lockwood@android.com>
robinz1x
Jerry Zhang
Yunlian Jiang
Daichi Hirono
Vitalii Tomkiv
Jaesung Chung
Tomasz Mikolajewski
Mike Lockwood
Bo Huang
Mark Salyzyn
Nick Kralevich
Steve Block
Mike Lockwood
Kenny Root