MTP, the protocol behind File Transfer mode, explained

MTP, the Media Transfer Protocol, is what an Android phone speaks over USB when you tap the "Charging this device via USB" notification and choose File Transfer (on a Pixel, File transfer / Android Auto). It is not a disk. The phone keeps control of its own storage and hands files to the computer one request at a time, as numbered objects rather than as blocks on a drive.

Windows has understood MTP for years, so on a PC the phone appears in File Explorer. macOS has never had MTP support of its own. That is why a Mac has always needed an app to reach an Android phone's files, and why those files usually live in that app's window rather than in Finder.

Where MTP came from

MTP grew out of PTP, the Picture Transfer Protocol that digital cameras use, standardised as ISO 15740. PTP was built for photos. Microsoft extended it in the early 2000s for music players and other media devices, and a Microsoft blog about it once joked that the name stood for "More Than PTP". Windows Media Player 10 brought a class driver for MTP devices, and new players sold under Microsoft's PlaysForSure label had to support it.

In May 2008 the USB Implementers Forum adopted MTP as a full USB device class, so it stopped being one company's protocol. Android picked it up in 2011. Honeycomb tablets such as the Motorola Xoom were the first to use MTP instead of showing their storage as a USB disk, and Google offered Android File Transfer for the Mac from the start, because macOS could not talk to them otherwise.

How MTP works

MTP has two roles. The computer is the initiator, which asks; the phone is the responder, which answers. Nothing happens unless the computer asks, apart from small event messages the phone may send, such as "a file was added".

Objects and handles

Every file and folder on the phone is an object with a number, its handle. To show you a folder, an MTP app asks the phone for the handles inside it, then asks for each object's details: its name, its size, its format, and the handle of its parent. Folders are objects too, of a kind MTP calls an association. There are no paths in the protocol itself. An app that wants to show DCIM/Camera has to walk from handle to handle to get there.

One operation at a time

Each exchange is a transaction: a request, an optional block of data, and a response. The specification makes these synchronous, so a new operation cannot start until the previous one has finished. Android's own MTP server reads one request, answers it, and only then reads the next, and it accepts a single session. In practice that means one program at a time can talk to the phone over MTP, and a long copy holds up everything else, including the next folder listing.

Reading and writing

Sending a file to the phone is two steps in the base protocol: describe the new object, then send all of its bytes. There is no standard way to change part of a file that is already there. Reading is more flexible: MTP 1.1 includes GetPartialObject, which fetches a byte range, although its offset is a 32-bit number. Google added its own extensions to Android's MTP, among them GetPartialObject64, SendPartialObject, TruncateObject, and a pair for editing an object in place. Whether you benefit depends on the app on the computer, because each one decides which operations it uses.

One more detail matters later. The record that describes an object stores its size in a 32-bit field, which tops out just under 4.3 GB. Larger files need a separate 64-bit property, fetched with a separate request, and not every app asks for it. That is the likely reason behind Android File Transfer's 4 GB limit.

Why a Mac cannot mount it on its own

A drive in Finder is a file system. macOS expects to ask for a file by its path, read any byte range of it, write into the middle of it, rename it in place, set its dates, and do several of these at once for different apps. MTP was designed for something narrower: a desktop music library handing whole songs to a media player. It offers objects by number, one transaction at a time, with editing in place only through Android's own extensions.

macOS ships nothing that translates between the two. Image Capture speaks PTP, the camera protocol MTP grew from, so it can import photos and videos from a phone set to PTP in its USB settings. It cannot browse the rest of the phone's storage, and it does not speak MTP.

So every MTP tool on the Mac brings its own translation. Most show the phone in a window of their own: Android File Transfer did, and OpenMTP, free and open source, still does. A few go further and build a Finder volume on top of MTP, turning each file system request into MTP operations: MacDroid, paid beyond a free tier, which can also use adb, and the new, free mtpfs for macOS 26. Building a full file system on a protocol that works one object at a time is real work, which is why there are far fewer of those than MTP apps.

What that means day to day

In an MTP app's window you browse, drag files out to the Mac, and drag files in. What you cannot do is treat the phone as a place where files live:

• Other apps cannot open a file on the phone. To edit a photo in Lightroom or play a film in VLC, you copy it to the Mac first, then copy the result back.
• Terminal and rsync cannot see the phone. There is no path to give them.
• Only one program at a time. If one app already holds the phone, the next one fails to connect, which is one cause of "Could not connect to device".
• Unlock the phone first. Google's own steps for File Transfer start with "Unlock your device".

Speed is not the problem it is often said to be. On a recent phone with a USB 3 cable, MTP moves large files quickly. A USB 2 phone or cable holds any method to about 20 to 40 MB/s. MTP's limits are in its model, not its throughput.

The other route over the same cable

Android has a second way to move files over USB: adb, the Android Debug Bridge, which its developer tools use. It needs USB debugging turned on once, and in return a computer gets a file copying service and a shell instead of a list of objects. adb versus MTP compares the two in detail.

SideMount takes that route. It speaks adb itself over the cable and presents the phone through FSKit as a volume in Finder, so any Mac app can open, save and copy files on the phone in place. It needs macOS 26 or later and USB debugging; the setup guide covers both.

Questions