[KopiasCsaba]

Type of change(s)

• Bug fix
• Feature / enhancement
• Infrastructure / tooling (CI, build, deps, tests)
• Documentation

What changed and why

Camera apps (e.g. Google Camera) insert a new photo as an IS_PENDING=1 MediaStore row first and finalize it a few seconds later. If you switch back to the gallery quickly, the reload on resume often runs while the photo is still pending, and the photo then doesn't show up until the next resume or a pull-to-refresh.

• Root cause: MediaActivity.gotMedia() stored the "latest media ID" baseline used by checkLastMediaChanged() after the fetch had finished. A photo finalized during the fetch was already part of the baseline but missing from the list, so the periodic check never saw a change. The baseline is now taken right before the fetch, using a new optional onBeforeFetch hook of GetMediaAsynctask that runs on the task's background thread. The cache path already took it before the fetch and is unchanged.
• React right away: while the folder is visible (onResume–onPause), MediaActivity observes MediaStore and runs the existing latest-media check shortly after a change (debounced by 500 ms, so bursts of notifications cause one check), instead of waiting up to 3 s for the next periodic check. If a reload is already running, it schedules exactly one follow-up reload after it instead of dropping the request. The periodic check stays as a fallback.

This PR only fixes the detection.

Tests performed

• Emulator (API 35, google_apis x86_64), Camera folder with ~6000 items. A camera was simulated with adb shell content commands (pending insert → write data → finalize), with the finalize timed to land during the reload on resume.
  • Before: the photo stayed missing (20+ s observed, periodic checks reporting no change) until the next resume or pull-to-refresh.
  • After: the change is detected ~0.5 s after the MediaStore notification (debounce), a follow-up reload starts ~4 ms after the running reload ends, and the photo appears. A burst of 4 notifications causes a single check.
  • With the fetch artificially slowed to phone-like duration (diagnostic build only): exactly one follow-up reload, and no extra reloads from the periodic check.
  • Resuming without new media triggers no extra reload; several photos in a row are all shown.
• Pixel 7a, Google Camera (reporter's device, 5700+ items in the Camera folder): logs confirmed the photo being finalized in the middle of the reload on resume. The old code then stored the new photo's ID as the baseline and never reloaded.
  • Before (F-Droid build): the photo didn't appear until switching away and back once more.
  • After (this branch alone): the photo appeared in all 5 runs, 10–76 s after switching back. Each reload of that folder takes several seconds on this device and is slowed down further by parallel rescans, which my further PR's will address.
• assembleFossDebug, :app:testFossDebugUnitTest, detekt and lint pass locally.

Closes the following issue(s)

• Closes Reload upon activity resume #284

Checklist

• I read the contribution guidelines.
• I manually tested my changes on device/emulator (if applicable).
• I updated the "Unreleased" section in CHANGELOG.md (if applicable).
• I have self-reviewed my pull request (no typos, formatting errors, etc.).
• I understand every change in this pull request.

[fossifybot]

Fossify accepts code contributions only for open issues labeled help wanted. This pull request does not meet that requirement or one of the documented exceptions, so it is being closed without review. Please read the contribution guidelines before starting work.