| Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
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
|
|
Change-Id: I5deef665ab374491c0f498b498971abd525d1111
|
|
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
|
|
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
|
|
Attempting to add a storage ID of 0 was causing a seg fault.
Change-Id: If8797186405be36ee70dbca63bd1063a62ba2812
|
|
Change-Id: Iac7852a4fb2add5744d5ea424d6ad5a82828f102
|
|
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
|
|
Change-Id: If8114b5eac741db6c512fb35cb48e3825c2ff098
|
|
Change-Id: Ic19ec61dc6cb08df00eb1326d96262b46bb93bfb
|
|
Change-Id: I9395481dd8d9cbd3346fe6682557236b48b4d6cd
|
|
Big thanks to Dees_Troy for helping with the implementation.
Change-Id: I6c9c522b9c9de5dc139e2ecb0141008182ba07f0
|