Photos Backup 0.3.5

Fixed

• "Google returned HTTP 400" during finalization now recovers instead of failing the photo. A live run against Google reproduced it: an upload whose receipt comes back without its upload token is committed anyway, Google answers "At least one valid blueprint is required", and every retry replayed the same dead receipt. The receipt is now checked where it is produced and where it is used, and a rejected one costs the item one fresh transfer rather than its whole retry budget. Receipts saved by older versions are checked too, so a queue carrying one from before the update recovers on the next attempt.

• A full Google account stops the backup and says so. It used to arrive as a generic HTTP failure, so the queue kept going and failed every remaining photo the same way, one at a time. Backup now pauses with an explanation and waits — freeing space and tapping Resume picks it back up. It does not ask you to reconnect the account, because signing in again does not free storage.

• Every upload commits under the quality setting you have selected now. The choice between original quality and Storage Saver, and whether the upload counts against your Google storage, was captured when the photo was prepared and then kept with it — so a photo prepared while Storage Saver was on kept uploading as Storage Saver after you turned it off, including after restarting the app.

Improved

• A failed upload will tell you what Google said. Tap a failed row for the full reason, selectable, with Copy Details. Diagnostics keeps the last 25 failures with their error codes and a Copy All, and counts how many there have been — the reason used to be a two-line caption that disappeared as soon as the row was retried or cleared.

• Error messages name what failed. "Google returned HTTP 400 during finalization" rather than "check your connection", and Google's own explanation is decoded instead of shown as a hex dump.

• A long backup no longer slows down as it progresses. The activity list, navigation, and the uploads themselves got slower the further into a whole-library backup you were: the queue's counters, its row lookups, and its search for the next upload all walked the entire queue on every progress update, and the per-album "backed up" counts re-scanned every selected album on each of those too. All of it is now maintained as it goes, so the cost no longer grows with the size of the queue.

Notes

• 132 tests, 130 passing (2 opt-in live tests skipped).
• Verified against Google with a fresh sign-in and synthetic images: authentication, duplicate check, and both the foreground and background upload paths all pass; the HTTP 400 above reproduces only with a deliberately emptied receipt. Why some devices produce an empty receipt is still open — this release makes the queue survive it.
• The Simulator cannot run background uploads or schedule background tasks. Use a device to exercise real backup behaviour.