# Media Transfer Protocol

The Media Transfer Protocol (MTP) is an extension to the Picture Transfer Protocol (PTP) communications protocol that allows media files to be transferred automatically to and from portable devices. Whereas PTP was designed for downloading photographs from digital cameras, Media Transfer Protocol allows the transfer of music files on digital audio players and media files on portable media players, as well as personal information on personal digital assistants. MTP is a key part of WMDRM10-PD, a digital rights management (DRM) service for the Windows Media platform. In 2011, it became the standard method to transfer files to and from Android.
MTP is part of the "Windows Media" framework and thus closely related to Windows Media Player. Versions of the Microsoft Windows operating system from Windows XP SP2 support MTP. Windows XP requires Windows Media Player 10 or higher; later Windows versions have built-in support. Microsoft has made an MTP Porting Kit available for older versions of Windows, back to Windows 98.
The USB Implementers Forum device working group standardized MTP as a full-fledged Universal Serial Bus (USB) device class in May 2008. Since then, MTP is an official extension to PTP and shares the same class code.

## Overview

MTP is a high level file transfer protocol, as opposed to a general storage protocol like USB mass storage. That means that the MTP client (computer) does not see an array of byte blocks that makes up a data structure that makes up a file system, but instead speaks in terms of files and folders to the MTP device. This lets the MTP device take part in the high level operations (such as updating its metadata indexes) while keeping the integrity of its file system in its own hands. In particular, dropped transfers (such as by unplugging the USB cable too soon) do not corrupt the device file system. The non-generality of MTP has consequences for how a computer operating system can present the MTP device, both to other programs and to the user.
According to its specification, the main purpose of MTP is to facilitate communication between media devices with transient connection. A secondary purpose being to enable command and control of the connected device. A battery-powered mobile device can report its battery charge level through MTP.
The protocol was originally implemented for use across USB but extended for use across TCP/IP and Bluetooth. Windows Vista supports MTP over TCP/IP. Windows 7 and Windows Vista with the Platform Update for Windows Vista also support MTP over Bluetooth. The host connecting to an MTP device is called an MTP Initiator, whereas the device itself is an MTP Responder.
MTP allows MTP Initiators to identify the specific capabilities of device(s) with respect to file formats and functionality. In particular, MTP Initiators may have to provide passwords and other information to unlock files, or otherwise enable digital rights management. Nothing specific of this nature is in the core standard, but the features are available via vendor extensions. MTPZ, the Zune Extension to MTP, specifically denies access to files until authentication has been processed, which is only possible using Windows Media Player 10 or higher.

## Comparison with USB Mass Storage

MTP's advantages are marked with "(+)" while disadvantages are marked with "(-)".

### File oriented instead of block oriented protocol

By not exposing the filesystem and metadata index, the integrity of these is in full control of the device.
* (+) No risk of file system corruption if unplugging the device while writing. File transfers are atomic, meaning completed in a single operation, and no explicit file system unmounting ("safe removal") is required by the user, since the file system remains managed by the mobile device's operating system, and a mobile device is battery-powered, meaning power to the flash memory is not cut out unexpectedly.
* The device can access its own file system while connected:
** (+) Re-indexing after unplugging can be avoided. Also helped by the inclusion of metadata with the transfer.
** (+) A separate file system for host exposure is unnecessary. This avoids the inflexibility of setting aside a fixed-size partition for this file system.
* (+) File system support: The host does not need to support the file system of the device. Conversely, the device manufacturer is free to choose a file system (usually a Linux filesystem unsupported by Windows) other than the widely supported FAT family of filesystems.
* (-) Undeletion: Filesystem recovery and undeletion tools on the computer cannot be used, since MTP is an abstraction layer that offers no block-level access.
* (-) Missing time stamps: Many MTP-attached devices, particularly older ones, do not report file timestamps via the protocol, causing them to be lost when files are copied/moved to or from a computer. Some file formats still store timestamps internally, such as JPEG photos with embedded Exif meta data, but the date and time information of files without such internal metadata would be lost.
* (-) Mislocation: Users have reported files occasionally showing up in incorrect locations as a result of poor communication between the MTP host (e.g. smartphone) and client (e.g. computer file manager). Should a directory be moved away from the MTP host without the client detecting all files, undetected files could end up deleted without all files having been transferred successfully.
* (-) Truncation: If a file has newly been created on the smartphone while it was connected to the computer through MTP, the computer's file manager could potentially misreport the file size as too small due to having loaded the directory listing in a moment where the file was not complete. Moving the file away from the phone could cause it to be truncated (incomplete) on the target path while being deleted from the source, since the file manager might wrongfully assume that the file has been fully transferred while it hasn't.

### Performance

* (-) MTP operations are not multiplexable – any ongoing operation must either complete or be aborted before another operation can begin. Unlike USB mass storage, where the host operating system is free to multiplex block transfers, and logical operations are an emergent phenomenon, the operations supported by MTP are more coarse-grained, such as transferring entire files. Neither protocol is parallel or asynchronous by itself (aside from the UAS extension of USB mass storage, which adds multiple command queues).
* (-) Limited support for transferring parts of files, such as blocks or byte ranges (see § Direct modification and partial transfer features).
* (-) Limited support for direct modification of files (see § Direct modification and partial transfer features). To modify a file or its metadata, the whole file may need to be copied out of the device and reuploaded, which takes a long time for a large file or directory, and blocks the device for other operations in the meantime. Google's MTP implementation in Android includes extensions to deal with this limitation; however, these extensions must be supported by the host operating system.
* (-) Loading long file listings of directories with thousands of items is slow. This could cause "preparing" for transferring files from highly populated directories to take longer than the file transfer itself, since the file manager needs to generate a list of paths to files it is about to transfer, which requires accessing the slow directory listings.

### Transparency to MTP-unaware software

(-) Windows does not assign drive letters or UNC paths to MTP devices because it does not natively expose them as virtual file systems. Without drive letters or UNC paths, MTP-unaware software cannot access directories or files on these devices. The user has to switch to an MTP-aware application, or else work around by using an MTP-aware application such as Windows Explorer to copy or move the file to a file system that the application can access.
One specific concern is that antivirus software on the host computer may not be aware of MTP devices, making them potentially less secure than mass storage devices (although if files on MTP devices are copied or moved to the host before use, MTP-unaware antivirus software will have a chance to scan them). Antivirus scanning might also be impractical due to blocking regular use of the device.

### Drivers know a fixed set of supported devices

(-) Despite identifiability by the PTP/MTP USB device class, libmtp documentation indicates that the vendor and product ID combination plays a functional role in identifying an MTP device, also by Windows drivers. Libmtp includes vast listings of vendor and product ID numbers of devices that it supports, along with workarounds for bugs. This non-generic methodology hinders MTP drivers' forward compatibility with new devices.

### The spec knows a fixed set of defined file formats

The MTP specification includes an enumeration of file formats, called object format. The use of this enumeration is in communicating supported file formats, and formats of transferred files. Apart from some uncategorized formats in the beginning, the list of formats is grouped in categories of image, audio, video and document formats, with each category having one "Undefined" format followed by specific formats. There is also a super-generic "Undefined object" format.
Jolla cited lack of WebM support in MTP as one reason not to support the video format in their mobile operating system Sailfish OS. It is unclear if the limitation is in the tools or the spec, other than that WebM is not defined by the MTP 1.1 spec.

## Direct modification and partial transfer features

These features can be used as more efficient alternatives to whole-file transfers and re-uploads:
From the MTP 1.1 spec:
| Opcode | Operation Name | Explanation |
| 0x9805 | GetObjectPropList | Metadata transfer |
| 0x9806 | SetObjectPropList | Metadata transfer |
| 0x1019 | MoveObject | Rename a file or directory |
| 0x101B | GetPartialObject | Request a byte range of a file |

### Android extensions

According to go-mtpfs:
| Opcode | Operation Name | Explanation |
| 0x95C1 | GetPartialObject64 | Same as GetPartialObject, but with 64 bit offset |
| 0x95C2 | SendPartialObject | Same as GetPartialObject64, but copying host to device |
| 0x95C3 | TruncateObject | Truncates file to 64 bit length |
| 0x95C4 | BeginEditObject | Must be called before using SendPartialObject and TruncateObject |
| 0x95C5 | EndEditObject | Called to commit changes made by SendPartialObject and TruncateObject |

## MTP support
### Windows
#### Adaption in Windows

MTP is supported in Windows XP if Windows Media Player 10 or later versions are installed. Windows Vista and later have MTP support built in. For older versions of Windows, specifically, Windows 2000, Windows 98 and Windows Me, Microsoft has released the MTP Porting Kit. which contains a MTP device driver. Some manufacturers, such as Creative Technology, also provide legacy MTP drivers for some of their players; these usually consist of MTP Porting Kit files with a customized INF file describing their specific players.

#### Support by software

Windows does not assign drive letters or UNC pathnames to devices connected via MTP; instead, they only appear as named devices in MTP-aware applications such as Windows Explorer. Compared to devices that implement USB mass storage, such devices cannot be accessed programmatically by scripts or normal Windows programs that depend on drive letters or UNC paths. Instead, files must be manipulated using Windows Explorer or applications with specially written MTP support.
Under Windows, MTP-compatible devices support a feature called Auto Sync, which lets users configure Windows Media Player to automatically transfer all copied or newly acquired content to devices whenever they are connected - provided that content is compatible with Windows Media Player. Auto Sync is customizable so that the player will transfer only content that meets certain criteria (songs rated four stars or higher, for instance). Changes made to file properties (such as a user rating and file playback counts) on a device can be propagated back to the computer when the device is reconnected.
Copies of files accessed over MTP may remain on the host computer even after reboot, where they will be accessible to the user account which accessed them, as well as any other user accounts able to read that user account's files, including any administrative users. Windows 7's sensor platform supports sensors built into MTP-compatible devices.

#### File move behavior

In the implementation of MTP used by Windows Explorer, files from a selection moved out of a mobile device's storage, perhaps with the goal of freeing up space, are not deleted individually from the source after each file, but instead the entire selection becomes deleted at once from the source only after the transfer has finished.
As a result, file moves aborted untimely, whether manually or unexpectedly, will not have freed up any space on the source device.

### Unix-like systems

A free and open-source implementation of the Media Transfer Protocol is available as libmtp. This library incorporates product and device IDs from many sources, and is commonly used in other software for MTP support.

#### Graphical

GNOME applications like GNOME Files (formerly called Nautilus) and Archive Manager (formerly called File-Roller) use GIO-based GVfs to access files on MTP devices. Proper MTP support was added to GVfs in version 1.15.2 (2013-01-15) by Philip Langdale. Early patches for GVfs to enable Google's direct I/O extensions are available.
The KDE Project develops the MTP KIO Slave with a similar level of integration as GVfs.
Not related to GNOME or KDE is the *NIX graphical MTP-capable media player, gMTP.

#### Virtual file system

Several tools provide a FUSE based file system for mounting MTP devices within the Unix filesystem hierarchy, making it accessible to any program that operates on files and directories.

#### macOS

macOS has built-in support for MTP (through the application "Image Capture") but no (third-party) drivers to mount MTP devices as drives. Also several third-party file transfer applications are available for Mac OS X v10.5 and later:
* Android File Transfer is a simple MTP client.
* Android File Transfer For Linux (and Mac OS X), Open Source, License GPL Version 3, Graphical UI, Command line tool, FUSE wrapper - mounting your device,
* OpenMTP - Open Source MTP client. Advanced Android File Transfer Application for macOS. Graphical UI. Faster transfer speeds than Android File Transfer.
* XNJB also offers syncing of iTunes playlists.
* SyncMate Expert claims to also support MTP besides other synchronization tasks. The support can't be tested in the free version.
* Commander One PRO Pack - file manager that allows mounting MTP devices to Mac and managing their content.

### Other operating systems

Later versions of several operating systems, including AmigaOS, Android, AROS, MorphOS, Symbian OS, and HarmonyOS/OpenHarmony/Oniro support MTP, sometimes with additional drivers or software.
A disadvantage of MTP devices on Android as compared to USB mass storage is that although file timestamps are preserved when copying files from the Android device to one's computer, when copying in the other direction, the file modification timestamps are replaced with the time the copy was done.

### Other manufacturers

Companies, including Creative Technology, Intel, iriver, and Samsung Electronics, that manufacture devices based on Microsoft's "Portable Media Center specification", have widely adopted MTP. Supporting devices were introduced at the 2004 Consumer Electronics Show.
After an initial period of uncertain reactions, several large media player producers such as Creative Technology and iriver adopted the MTP protocol in place of their own protocols.
Many devices and audio software applications support MTP.

## Alternatives

* USB Mass Storage
* Network-attached storage (NAS)