Not sure what kind of APIs should be exported as WEB APIs. But, we must at least notify the user to allow or deny an MTP session. MTP can be used over USB, Bluetooth, and TCP. This bug focus on over USB. There is several candidates for being data sources of the MTP server. MediaStorage can be one of data provider. Others can be bookmark, phone book, ...etc.

I'll bring this up in the WebAPI meeting today. I know we definitely plan on this interacting with media storage, might be good to plan a meeting between Jonas/MedisStorage people and whoever is implementing this.

Or... not, no WebAPI meeting today since a decent bit of the team was out. I'll try to figure out who's working on what over here and get them CC'd on this though.

There are a few things here - we need to actually support MTP in b2g/gonk ;) - allow users to connect/disconnect MTP - when MTP is being used, we need to disconnect MediaStorage clients (i.e. deny their requests). Only the third item affects developer-facing APIs initially. The MediaStorage API needs to notify clients when they're "kicked off", or their requests are blocked, same as for USB mass-storage mode. At any rate, we need to be sure to account for that.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #3) > There are a few things here > - we need to actually support MTP in b2g/gonk ;) > - allow users to connect/disconnect MTP > - when MTP is being used, we need to disconnect MediaStorage clients (i.e. > deny their requests). It would be better if MediaStorage is capable for creating a snapshot. Most requests are about C, R, D of CURD. Updating is few. MediaStorage doesn't provide the function of partially updating(?) It is not necessary to kick off clients.

It looks like under android there are only 2 controls: 1 - Enable MTP 2 - Enable PTP The is an MTP API, but that's when the phone is acting as a host and you connect a camera or similar device to the phone.

MediaStorage allows updating existing files.

But that happens by having the host open the file, write some changes and close it. Which seems to happen more or less transparently to the phone. i.e. it behave more or less like you had NFS mounted the phone from the PC and updated files. The only quirk that I've noticed is that files added to the file system by the phone after MTP has mounted the phone aren't seen by the host. The host seems to enumerate the files once. If you unplug and replug the USB cable then the host sees the new files. Files copied from the host to the phone are seen immediately by the phone.

I meant, web apps on the phone can update files while the host is connected over MTP. Which means it's impossible in general to send the host a consistent view of a particular file. Similarly for web apps on the phone, if the host is simultaneously modifying the files, they'll see an inconsistent view in general.

(In reply to Dave Hylands [:dhylands] from comment #7) > But that happens by having the host open the file, write some changes and > close it. Which seems to happen more or less transparently to the phone. > i.e. it behave more or less like you had NFS mounted the phone from the PC > and updated files. From the spec of MTP, if I am right, it allows only to send an object wholly. You can not update only a byte or a block of a file and close it.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #8) > I meant, web apps on the phone can update files while the host is connected > over MTP. Which means it's impossible in general to send the host a > consistent view of a particular file. Similarly for web apps on the phone, > if the host is simultaneously modifying the files, they'll see an > inconsistent view in general. Do we lock files to avoid more than one applications to read/write it? If we don't, I don't see any reason that MTP is so special. If we do, MTP has "BUSY" condition for that.

We should! OK, that's interesting. In that case, it's a UX decision for whether we forceably unmount existing users. (A web page can keep a file opened for writing for an unbounded amount of time, which prevents the host from reading it.)

I'll do some experiments to see whether the host can open files etc while the phone has them open. If the host can only send a file wholly, then the typical behaviour will probably be that the phone will retain the one inode. The host will replace the file and when the phone closes and reopens the file it will see the new contents. Anyways, some tests should establish what happens. Unless MTP has specific APIs for locking, then I doubt any locks will be held. I've been able to MTP mount SGS2 running android from windows, but not yet from linux.

Cervantes and I are trying to work out a prototype. And, we have tried to use wireshark to capture USB on Linux. With virtualbox on Linux, we can capture MTP traffic from Windows to device. We will try figure out what requests are actually sent by windows later. Cervantes has used gphoto2 to list objects on a device successfully. We plan to start the prototype from here, and do compatibility testing with windows some time later.

Here's what I've discovered so far from code examination. A portion of the code resides as a USB gadget driver, code found in boot/kernel-galaxy-s2-ics/drivers/usb/gadget/f_mtp.c There is some C++ user-mode code (not in our glue/gonk tree, but in android) frameworks/base/media/mtp (mostly in MtpServer.cpp and MtpDevice.cpp), and there is a very small java component (frameworks/base/media/java/android/mtp/MtpServer.java). The file opens takes place from the C++ code, using open( with O_RDWR | O_CREAT | O_TRUNC ) for the write case, and O_RDONLY for the read case. I couldn't find any locking code. The bulk of the file I/O takes place from kernel space in the gadget driver. I found no references to MTP_RESPONSE_DEVICE_BUSY other than its definition. And even if it was used, it would be going back to the host, and not to any software on the PC. Since a portion of the code is written in java, we'll obviously need to replace that portion. We could reuse some or all of the C++ code and by rewriting a portion we could introduce file locking.

I've also done some investigation in regards to file locking in linux. For the most part locking is advisory only, so all parties have to be using the same locking mechanisms. If A opens and locks a file, and B decides not to acquire a lock (Perhaps I do ls -l > file.txt) then the file will happily be overwritten. I have a little test program that I've written for playing around with file locking. If you'd like a copy, let me know.

With no SD Card, the phone will automount under ubuntu 12.04 and show me the contents of /sdcard. However I can't see the contents of any folders, and only see files in /sdcard itself. It seems to be using gphoto2 to do the mount, so I'm not convinced this is using MTP (and probably using PTP) With a physical SD Card in the phone, when I plug in the phone, I get the error: Unable to mount SAMSUNG_Android Error initializing camera: some error (usually -53 or -60)

(In reply to Dave Hylands [:dhylands] from comment #14) > Here's what I've discovered so far from code examination. A portion of the > code resides as a USB gadget driver, code found in > boot/kernel-galaxy-s2-ics/drivers/usb/gadget/f_mtp.c There is some C++ > user-mode code (not in our glue/gonk tree, but in android) > frameworks/base/media/mtp (mostly in MtpServer.cpp and MtpDevice.cpp), and > there is a very small java component > (frameworks/base/media/java/android/mtp/MtpServer.java). The gadget driver for MTP is only a transport layer. You read/write requests and responses through file IO, and send/receive events and objects through ioctl. For example, you should pass a fd to gadget driver through ioctl for receiving or sending a file. It is very similar to FTP with two TCP connections, one for commands and another for data. > > The file opens takes place from the C++ code, using open( with O_RDWR | > O_CREAT | O_TRUNC ) for the write case, and O_RDONLY for the read case. I > couldn't find any locking code. > > The bulk of the file I/O takes place from kernel space in the gadget driver. > I found no references to MTP_RESPONSE_DEVICE_BUSY other than its definition. > And even if it was used, it would be going back to the host, and not to any > software on the PC. gadget driver for MTP is noly a transport layer for the protocol. All request/response/events/and object (file) content are made by user space MTP server. MTP can be over TCP/USB/Bluetooth, USB is only one of transports. MTP server is more like what FTP server is. So, you are not supposed to see MTP_RESPONSE_DEVICE_BUSY in the gadget driver. It more like a part of MTP server.

(In reply to Thinker Li [:sinker] from comment #17) > > The file opens takes place from the C++ code, using open( with O_RDWR | > > O_CREAT | O_TRUNC ) for the write case, and O_RDONLY for the read case. I > > couldn't find any locking code. > > > > The bulk of the file I/O takes place from kernel space in the gadget driver. > > I found no references to MTP_RESPONSE_DEVICE_BUSY other than its definition. > > And even if it was used, it would be going back to the host, and not to any > > software on the PC. > > gadget driver for MTP is noly a transport layer for the protocol. All > request/response/events/and object (file) content are made by user space MTP > server. MTP can be over TCP/USB/Bluetooth, USB is only one of transports. > MTP server is more like what FTP server is. So, you are not supposed to see > MTP_RESPONSE_DEVICE_BUSY in the gadget driver. It more like a part of MTP > server. So the C++ code I was referring to is the user-space code and not from the gadget driver. The file opens, and not seeing any BUSY stuff were all referring to user-mode code and not the gadget driver.

This IDL defines interfaces for implementations of transports and service of MTP responder. nsIMTPResponderService is responsible for implementing MTP protocol by handling requests and events, and generate response, event, and data payloads. nsIMTPTransport is implemented by transports. Transports are responsible for handling connections and transfer packets between an initiator and a responder.

It is the interface between the MTP responder and backends storage implementation; for example, DeviceStorage. For DeviceStorage, we need an nsIMTPStorageProvider as a glue that the MTP responder can use DeviceStorage as a backend storage.

Apps (Gallery, Music, etc.) that use the DeviceStorage API need to know when files are added or removed from their storage areas. In the general case, they have to implement "rescan media" features. But it would be really nice if there was an optimimzed path to be notified when MTP is used to add or delete files. Is there any way we can make DeviceStorage and MTP interoperate a bit? Maybe MTP could maintain a journal of the changes it makes? And DeviceStorage could define a method to query that journal for changes after a given timestamp? And, if DeviceStorage has to change to disconnect clients when an MTP session begins, then maybe it can send an event with the changes when the MTP session ends.

Thinking about my comment above some more, I realize that if MTP is going to be implemented on top of DeviceStorage, then things become simpler and it can be DeviceStorage that maintains the journal of changes.

Thinker, do you still plan to work on that?

Alan Huang is working on this now.

Cleaning up Device Interfaces component, and mass-marking old FxOS bugs as incomplete. If any of these bugs are still valid, please let me know.