File Bridge 1.11.0 — large downloads survive the screen going off

Server 1.11.0 · Mac app 1.11.0 · Android app 1.10.0 (versionCode 11)

A large file sent to the phone would stop partway through and never recover. It
took four attempts to pin down because Android reports one generic "Unable to
download" for every possible cause. Two separate faults were stacked on top of
each other.

The server never sent a validator

/file advertised Accept-Ranges but no ETag. Android's DownloadManager
stores the ETag from the first response and replays it as If-Match alongside
Range: bytes=N- when it resumes — with no ETag it decides the download cannot
be resumed and fails outright the first time a connection drops.

The server now sends ETag and Last-Modified, falls back to a full 200 on a
stale If-Range, and answers 412 to a stale If-Match rather than splicing
bytes from two different files together.

DownloadManager still would not resume

It runs transfers as JobScheduler work and holds no wifi lock, so when the
screen went off the radio slept and the transfer was dropped as "network lost".

The Mac's transfer log made it unarguable: three attempts at a 707 MB file,
killed at 15.8 s, 15.9 s and 16.2 s — three different byte counts, one
clock, matching the phone's 15 second display timeout. Not one ranged request
afterwards, even with the ETag in place.

So the app does it itself. DownloadService is a foreground service holding a
WifiLock and a partial WakeLock while bytes are moving, with its own resume
loop: Range plus If-Match after every drop, backoff between attempts, and a
give-up only after eight attempts that move no bytes at all. Any progress resets
the count, so a link that drops every fifteen seconds still finishes. A partial
file survives a give-up, so downloading the same file again continues from where
it stopped.

Files are written through MediaStore on Android 10+ and as plain files below
that. The notification shows progress, rate and a Cancel action. Failures are
now sentences describing what happened, reported on resume so they survive the
app being killed mid-transfer.

Also here

Every transfer is logged on the Mac with how it ended, bytes sent, duration,
rate and the requested range (~/.filebridge/gui.log). That log is what turned
three equally plausible theories into one measurement.

Installing

Attached APK is FileBridge-1.10.0.apk, versionCode 11 — it upgrades in place.
Debug-signed, so Android will warn about an unknown source. Update the Mac side
too: the resume only works with server 1.11.0.