v1.4.5

Everything here is about waiting less. All of it was measured on an SM8350, old build against new on the same session.

Restarting the modem: 8.1s → 3.1-6.2s

The helper used to sleep a flat 8 seconds and hope the modem was back. It now watches the QRTR bus instead: DIAG is registered again when the modem is up, and that is the moment the session is rebuilt. So the wait is as long as the restart really takes, and no longer — and a modem slower than the old 8 seconds is no longer given up on, which it used to be.

Every change commits ~3x faster

Since 1.4.1 each delete, mkdir, chmod, save and NV write commits the EFS journal, and that commit waited up to a second for a "done" this target never reports. 1.03s → 0.11-0.32s, on every one of them.

Flush EFS journal twice in a row used to sit for 1.2 seconds and then report efs errno=306. Nothing has changed since the last commit in that case, so the helper no longer asks the modem at all: it is instant, and it is not an error.

Connecting: about a second quicker

Starting the helper waited a fixed second. It now waits for the helper to say it is listening — 1.03s → 0.03-0.12s.

File-by-file backup: a quarter faster

The walk stated every file for a size the directory listing had already given it. That round trip is gone: over 52 files, 271 DIAG round trips → 219, 0.58s → 0.45s. Empty files cost nothing at all now.

Two other ideas were measured and dropped: this modem caps every read at 1024 bytes however much is asked for, and item files open through the ordinary file interface perfectly well, so neither bigger chunks nor a different item-file path had anything to give.

Housekeeping

Listings were being sorted twice, the inline-read limit was written down in two places (the helper reports it now), the hex dump formatted every byte through String.format, and Ui.kt had grown to 1300 lines — it is now three files. No visible change from any of it.

The bundled helper is 1.4.5, matching the app.