Every number, and what it was taken on

• Off the phone

  Sustained across 4,521 reads without drifting. The slowest run averaged 35.1 MiB/s and the fastest 38.9; the spread inside a run was under 3.

  35–39 MiB/s

• Onto the phone

  The phone's own flash is the limit here, not the cable. Measured at 18 MiB/s on 15 September with the phone half empty, and at 11.6 on 21 September with it 90% full — which is the more useful of the two to know about.

  11.6–18 MiB/s

• Opening a folder

  A camera folder of 360 items, listed in one request per property rather than one per file. The first listing after plugging in is far slower — about 25 s while the phone indexes everything on it — and every one after that is this.

  0.5 s for 360 files

• Arriving intact

  Every copy of every file was hashed and compared. Across 111 GiB, including 45 copies of a 512 MB file, every hash matched. Not one byte arrived wrong.

  SHA-256 identical, 111 GiB

• You shut the laptop mid-copy

  The Mac sleeps — nothing an application can do prevents that for a closed lid, and the system log confirms it. The question is what survives.

  The copy survives. A 50-second sleep landed in the middle of a read: the transfer was frozen, the Mac woke, and it finished correctly.

  The bytes survive. That run's hash matched a run with no sleep in it exactly, so nothing was corrupted by being interrupted.

  965 reads across the sleep · 0 lost · SHA-256 unchanged

• The cable comes out mid-copy

  This one cannot be recovered from, and that is the phone's decision rather than the app's: on replug, Android goes back to no data transfer and waits for somebody to tap File transfer on the screen. No amount of retrying reaches across that.

  The copy stops. It cannot continue by itself, and the app says so once rather than failing every remaining file separately.

  Nothing is lost. The partial file keeps its .part name, so it never looks finished, and copying again carries on from the bytes already there.

  Resumed from .part at 37.9 MiB/s, SHA-256 identical

• The phone is not in the right mode

  A phone set to Transfer photos still reports a storage of the right size, so nothing about the storage gives it away. Three signatures do.

  File transfer — product id FF40, the vendor MTP interface, and the phone says it speaks MTP.

  Photo transfer — product id FF10, the still-image interface, and it does not.

  All three measured on the phone · macOS's own USB log agrees on the id

There are five of these states in the app, not two, and each one gets its own wording and its own instruction — a locked phone, one set to Photo transfer, another program holding the cable, nothing plugged in, and a phone that has stopped answering.

• Whether locking the phone stops a running copy.

  Two measurements a few days apart contradicted each other, and the runs meant to settle it were labelled from what someone reported rather than from anything read off the cable — so they settle nothing. The app and this site therefore still say what they said before: keep the phone unlocked while a copy runs. It is the honest answer, not the flattering one. OpenMTP keeps a help entry for the same symptom — a phone that disconnects when its display sleeps, disrupting a transfer already running — and calls it rare, with seven years and far more phone models behind that word. That is their report and not a measurement made here, so it settles nothing either. But rare is the shape this evidence has: one run saw it, and the thousands of reads since have not.

• How it behaves on any phone but this one.

  One model, one Android version, one manufacturer's software. Samsung is the one competitors get the most complaints about and has never been tried here.

• Anything about SD cards.

  The test phone has no card slot in use, and the app reads only the first storage a phone offers, so a card is invisible to it today.

• How it compares with OpenMTP for speed.

  The two have never been run against the same folder back to back. The comparison page says what could be established without that, and says plainly that the speed question is not part of it.

• A phone holding far more than 34,000 objects.

  That is roughly where this one sits, and the first listing after plugging in already takes about 25 seconds at that size. Nobody knows what a much fuller phone does.

Every figure on this page comes from NOTES.md in the app's repository, which records the conditions of each one — and, where a conclusion was drawn and later withdrawn, records that too.