summaryrefslogtreecommitdiffstats
path: root/mtp/ffs/mtp_MtpServer.cpp (unfollow)
Commit message (Collapse)AuthorFilesLines
2019-03-20MTP FFS updates:bigbiff bigbiff1-20/+47
This update splits old MTP code and new MTP code from Google into two trees, legacy and ffs. Depending on the SDK level, the build system will select the correct version. The reason for separating the versions out are due to older android trees not supporting the updated MTP code from Google. Most MTP code is from Google, with additions needed from implementing the Java functions in C++ for TWRP and FFS. We assume if you are in android-9.0 or above, your kernel has support for FFS over MTP. Verify that your init.rc is mounting the MTP FFS driver to the proper location. Change-Id: I4b107b239bd9bc5699527f9c8c77d9079f264a7e
2017-11-28Support v2 fstab formatEthan Yonker1-1/+1
Auto detect and support both the v1 and v2 fstab formats Support putting TWRP style flags in a separate /etc/twrp.flags file twrp.flags format is the same as twrp.fstab (v1 with TWRP flags) Support using a wildcard in a block device and find all partitions: /usb-otg vfat /dev/block/sda* Support using sysfs entries (voldmanaged) and read uevents and scan for wildcard partitions from uevent data. (twvold?) May not be complete for some of the newer flags found in fstabs in newer build trees and there is a slim chance of a crash if the user removes a removable device while TWRP is performing actions. May need to add some kind of mutex to prevent the 2 threads from causing this crash. We need to start somewhere though and this change is pretty innocuous when not using a v2 fstab. Change-Id: I617d97c7db332cbe671a9d2b8ad98b3d9c4f03cc
2016-01-29Remove execute permissions from source filesthat1-0/+0
Change-Id: I5deef665ab374491c0f498b498971abd525d1111
2015-02-02MTP: make MTP work even if unplugged and repluggedEthan Yonker1-32/+24
Set up a loop to keep trying to open / read the MTP device so that MTP will work even if the device is unplugged during boot or unplugged and replugged in. Change-Id: I0d3a3b7c91ce84a8cbed16caa4b15efee35b3641
2014-12-29Move sleep during MTP startup to MTP threadEthan Yonker1-0/+5
Some devices are very slow to respond to the sysfs requests. To prevent delaying the main GUI from booting during TWRP startup, we move the sleep delay to just before we open the MTP device and into the MTP thread so that it does not hold up the main TWRP thread. Change-Id: Ic931ef317d0fb7ef4dfdef46a32f68a014ff62c0
2014-12-29Check for valid MTP_Storage_ID before adding or removingEthan Yonker1-5/+9
Attempting to add a storage ID of 0 was causing a seg fault. Change-Id: If8797186405be36ee70dbca63bd1063a62ba2812
2014-12-22Fix else if and maxFileSize initializer.bigbiff1-1/+1
Change-Id: Iac7852a4fb2add5744d5ea424d6ad5a82828f102
2014-12-19MTP add/remove storage instead of disabling MTPEthan Yonker1-1/+51
Implement a pipe between TWRP and MTP to allow TWRP to tell MTP to remove storage partitions as they become unavailable (e.g. during a wipe, unmount, etc) instead of disabling MTP completely. This includes some fixes and improvements in destructors to properly remove / delete various items. This also means that we will not be toggling adb off and on quite as often. I do not like that we had to add another thread, but we were unable to use select() on the mtp_usb character device because this device does not support polling. Select always returned indicating that the mtp file descriptor was ready to be read and the resulting read would block. The read block prevented us from being able to include reading of the pipe between TWRP and MTP in the main MTP thread. We might want to add a return pipe letting TWRP know if the removal of the storage device was successful, but I am not sure how we want to implement this. It would invovle timeouts in both TWRP and MTP to ensure that we returned a failure indicator in a timely manner to TWRP and prevent deleting the storage device in the case of a failure. Right now we make no attempt to ensure that an MTP operation is underway like a large file transfer, but we were not doing anything like this in the past. In some respects we have limited control over what happens. If the user installs a zip that unmounts a storage partition, we will not know about the change in storage status anyway. Regular Android does not have these troubles because partitions rarely get unmounted like in recovery. At some point, we have to hold the user accountable for performing actions that may remove a storage partition while they are using MTP anyway. Ideally we do not want to toggle the USB IDs and thus toggle adb off and on during early boot, but I am not sure what the best way to handle that at this time. Change-Id: I9343e5396bf6023d3b994de1bf01ed91d129bc14
2014-12-04add function to partition.cpp to return max file size to mtp responderbigbiff1-1/+1
Change-Id: If8114b5eac741db6c512fb35cb48e3825c2ff098
2014-09-11MTP: Build flag for setting custom MTP device/pathEthan Yonker1-2/+4
Change-Id: Ic19ec61dc6cb08df00eb1326d96262b46bb93bfb
2014-09-03Improve error handling during MTP startupEthan Yonker1-5/+8
Change-Id: I9395481dd8d9cbd3346fe6682557236b48b4d6cd
2014-09-03add mtp responder to TWRP.bigbiff bigbiff1-0/+143
Big thanks to Dees_Troy for helping with the implementation. Change-Id: I6c9c522b9c9de5dc139e2ecb0141008182ba07f0