fix: StreamingService foreground crash, import crash, and sync change-detection bugs

[7MS8]

Problem

Six bugs fixed in this PR, found and fixed while getting Round-Sync working reliably on GrapheneOS against a Synology SFTP remote.

---

Fix 1: StreamingService killed immediately on GrapheneOS

On GrapheneOS (and any Android variant with strict foreground service enforcement), the streaming / file-browser feature does not work. The rclone serve http process starts but is killed within 2–30 seconds before the WebView can load the file listing.

Root cause: StreamingService extended the deprecated IntentService. startForeground() was called from a background worker thread (onHandleIntent), not from the main thread in onStartCommand. Android requires startForeground() within 5 seconds of startForegroundService(). On GrapheneOS this window was consistently missed.

Fix:

• Convert StreamingService from IntentService to Service
• Call startForeground() immediately in onStartCommand() on the main thread
• Run blocking waitFor() in a dedicated thread; return START_NOT_STICKY
• Add tryStartForegroundService() to ActivityHelper; use it for all StreamingService start calls

---

Fix 2: Settings import crashes on backups without a filters array

Importer.createFilterList() called reader.getJSONArray("filters") which throws JSONException when the key is absent. The filters array was added later and is missing from all pre-existing exports (including the current F-Droid release v2.5.6). This exception aborted the entire import — rclone.conf was already written but tasks and preferences were silently skipped.

Fix: Replace getJSONArray() with optJSONArray() + null-check for filters, tasks, and trigger arrays in Importer.java.

---

Fix 3: log2File never initialized in SyncWorker/EphemeralWorker

Follow-up to Fix 2 — after fixing import, sync logging (log2File) was never initialized in these two workers, so sync log entries were silently dropped in some code paths.

---

Fix 4: rclone INFO output not visible in the in-app sync log

rclone's own progress/status output (transferred bytes, errors, "nothing to do", etc.) wasn't being captured into the in-app sync log, making it hard to diagnose sync issues from within the app. Now captured at INFO level.

---

Fix 5: SFTP sync fails on restricted shells + -vvv/--log-level conflict

Two related SFTP/logging issues:

• Synology (and similar) restricted SSH shells can't run md5sum/sha1sum over SSH even though the files are reachable via SFTP, causing corrupted on transfer: hashes differ failures on every transfer. Fixed by setting --sftp-md5sum-command none --sftp-sha1sum-command none for SFTP remotes.
• When debug logging is enabled, -vvv was being combined with --log-level INFO, which rclone rejects (Can't set -v and --log-level), causing rclone to exit immediately with no useful output.

---

Fix 6: Changed files silently skipped by sync — two compounding bugs

Reported symptom: sync appeared to detect changes "only by file size, not by date" — files with the same size that had genuinely changed content were never re-synced.

Bug 6a: Fix 5's --sftp-md5sum-command none combined with --checksum (set when "use checksum" is enabled on a task) left rclone with no common hash type to compare. rclone silently fell back to a size-only comparison. Fixed by not setting --checksum for SFTP remotes — rclone then uses its default size+modtime comparison instead.

Bug 6b (the actual root cause): RCLONE_LOCAL_NO_SET_MODTIME=true has been set for every rclone invocation since 2021 (to avoid old chtimes crashes, ref rclone#2446). In current rclone this makes the local backend's Precision() report ModTimeNotSupported unconditionally, which makes rclone's default comparison treat any same-size file as unchanged — skipping modification-time comparison entirely, for every task regardless of remote type or checksum setting. Verified in the vendored rclone v1.71.0 source that a failing chtimes()/SetModTime is not fatal (just logged and counted, transfer still succeeds), so the 2021 workaround is no longer needed and was silently breaking change detection. Removed from both Rclone.java and RcloneRcd.java.

Both 6a and 6b were verified against a live Synology SFTP remote: a same-size, content-changed file is now correctly detected via modtime and re-transferred, a second sync correctly no-ops once genuinely in sync, and the local destination's mtime is now correctly set to match the source with no chtimes errors logged.

---

Test plan

• File browser / streaming works on GrapheneOS Pixel without serve process dying (emulator-verified, GrapheneOS hardware test still pending)
• Cancel notification button still stops the serve process
• Settings export from v2.5.6 F-Droid release imports successfully into patched build
• Tasks and rclone.conf are imported correctly from backup ZIP
• SFTP sync against Synology restricted shell no longer fails with "corrupted on transfer"
• Same-size, content-changed file on SFTP remote is now correctly re-synced (verified live, both with and without "use checksum" enabled)
• Unchanged files are not needlessly re-transferred on subsequent syncs
• No regression on stock Android

🤖 Generated with Claude Code

[7MS8]

Update: Added Fix 3 — External log file was never written.

log2File was declared in both SyncWorker and EphemeralWorker but never initialized, so log2File?.log(line) was always a no-op regardless of the logging preference setting. Also added a null guard in Log2File.log() for cases where getExternalFilesDir() returns null.

Commit: a746cab

[scr4bble]

@7MS8 thanks for the fixes! I have a question though.

Synology (and similar) restricted SSH shells can't run md5sum/sha1sum over SSH even though the files are reachable via SFTP, causing corrupted on transfer: hashes differ failures on every transfer. Fixed by setting --sftp-md5sum-command none --sftp-sha1sum-command none for SFTP remotes.

Can you explain your thoughts behind this change? Have you considered any other solutions for this issue? I am probably not convinced that disabling it for all SFTP remotes is a good idea but I didn't go too deep here so that's why I am asking.

Fix 2: Settings import crashes on backups without a filters array

I can confirm this bug - not sure if it's reported (haven't found such issue opened). I have just tested an import from a ZIP that was exported from 2.5.6 fdroid installation and I only got remotes populated but no tasks were imported. It also showed an error but probably a wrong one (something about tasks and triggers missing in the archive - most likely caused by missing filters though).

@newhinton by any chance - will you have any capacity to look at this PR and maybe provide a bit of feedback? Should it be split into more PRs? Which of these fixes are good to be merged and which ones would you want to be discussed?

[7MS8]

Thanks both for taking a look, and Peter for the review!

On disabling --sftp-md5sum-command/--sftp-sha1sum-command for all SFTP remotes:

The original problem (fixed in 9926e3f): Synology's SFTP-only restricted shell has no full SSH shell access — md5sum/sha1sum binaries aren't reachable via SSH even though the files themselves are reachable via SFTP. rclone's --checksum behavior tries to call these remote commands to verify transfers, and on these shells every single transfer failed with "corrupted on transfer: hashes differ" — not occasionally, 100% of the time whenever md5sum verification was enabled. Disabling those remote hash commands for SFTP was necessary to make transfers succeed at all on this class of server.

That fix introduced a second, more subtle bug (fixed in 8b62460): with the remote hash commands disabled, combining that with --checksum leaves rclone with no common hash type to compare — and rclone's response is to silently fall back to a pure size comparison, ignoring modification time entirely. I verified this against a live Synology SFTP remote: a file with the same byte size but changed content and a newer mtime was silently skipped on sync — a worse failure mode than the original bug, since it doesn't error, it just quietly doesn't sync. So the second commit skips --checksum for SFTP remotes entirely, letting rclone fall back to its own default size+modtime comparison.

Alternatives I considered:

• Detect the restricted-shell case dynamically (probe whether md5sum is reachable, or catch the specific error and retry with hashing disabled) — more correct, but adds complexity and at least one wasted failed transfer per file to detect it. Didn't want to scope-creep this PR.
• Per-remote opt-out toggle instead of an unconditional default for all SFTP remotes — I think this is actually the better long-term answer, and your pushback is fair: an SFTP server that can run md5sum/sha1sum over SSH (plenty can) loses transfer-time hash verification under the current change, which is a real regression for that case. I didn't build this into the PR because I only had a Synology remote to test against and didn't want to guess at a config surface without more cases in hand.

Happy to follow up with a per-remote toggle if that's the preferred direction — let me know and I can open a follow-up PR instead of changing the SFTP default further here.

On the import crash (Fix 2): thanks for confirming the repro. What you're seeing ("remotes populated but no tasks imported") is explained precisely by the bug: Importer.importJson() calls createTriggerlist(), then createFilterList(), then createTasklist() in that order, and (before this fix) createFilterList() threw a JSONException on any backup missing the "filters" key — which is every backup from before filters existed. Since that exception wasn't caught per-section, it aborted the whole importJson() call, so createTasklist() (called after) never ran. That's also why the error message was misleading — it's a generic top-level catch, not specific to the actual missing key. The fix (6a927ad1) makes each section optional via optJSONArray() instead of getJSONArray(), so a partial/older backup still imports whatever sections are present.

@newhinton whenever you have a chance, feedback on scope would help — happy to split this into separate PRs per fix if that's easier to review than one bundled diff.

[scr4bble]

@7MS8 Nothing against using AI to help write or refine a message, but please consider other people’s time as equally valuable as your own. Nobody enjoys reading that much AI-generated text. The less effort you put into editing and condensing the real valuable information in the text, the more effort everyone else has to spend parsing it.

“More correct, but adds complexity and at least one wasted failed transfer per file to detect it. Didn’t want to scope-creep this PR.”

Do you really stand behind this statement? Why would detecting it require one failed transfer per file?

In general:

1. From a prioritization perspective, it is usually better not to combine unrelated changes into one PR unless they genuinely need to be merged together.
2. A larger scope makes the PR slower to review, iterate on, merge, and test.
3. You should provide a solid reproducer so others can verify both the bug and your solution. That should include the app version, the exact commit to check out, the rclone configuration, the task configuration, the observed errors, and clear reproduction steps.

One final point: if you keep feeding my replies back into AI and sending me another generated response, I don’t think this discussion will get very far.

I think a good starting point would be to split the unrelated fixes into separate PRs and take them step by step. For smaller PRs that do not already have a corresponding issue, please also spend a bit more time explaining how to reproduce the particular problem so others can review and test your solution too if they have the capacity.

[7MS8]

Hi Peter,

Fair point, and sorry — I don't have the technical background to defend the specifics or dig into the scope/reproducer questions myself. I just wanted the app to sync reliably with my NAS, and Claude Code did the actual fix over about half a day; I only ran the tests and managed the process. So I can't really engage with your questions on the merits.

If it helps in the meantime, you can find a built APK with these fixes on my fork's releases (7MS8/Round-Sync, tag v2.5.6-grapheneos-fix-2) if you'd rather test directly than build from source.

I'll split this PR into separate, smaller PRs per your suggestion so each fix can be reviewed on its own. Will follow up here once they're up, and close this one out.

Thanks a lot for taking the time to review this so carefully.

Michael

[7MS8]

Split into 6 separate PRs, one per fix, each with its own reproduction steps:

• fix: promote StreamingService to foreground immediately on Android 8+ #408 — GrapheneOS StreamingService foreground fix
• fix: don't crash import when backup has no filters/tasks/triggers array #409 — Import crash on missing filters/tasks/triggers array
• fix: stop forcing size-only sync comparisons via RCLONE_LOCAL_NO_SET_MODTIME #410 — RCLONE_LOCAL_NO_SET_MODTIME removal
• fix: enable in-app sync logging (log2File init, INFO/NOTICE capture, log-level conflict) #411 — Sync logging (log2File init, INFO/NOTICE capture, log-level/-vvv conflict)
• fix: guard postSync() against uninitialized mTask #412 — postSync() uninitialized-mTask crash guard
• fix: SFTP sync failures from restricted-shell md5sum and checksum fallback #413 — SFTP checksum/hash handling (the part under discussion above)

Closing this one in favor of those. Thanks again for pushing for this — happy to keep discussing the SFTP hash-verification tradeoff on #413.