Skip to content

Backup & Sync: configurable daily backup time (default 1am) - #13

Merged
ryanbr merged 1 commit into
mainfrom
snapshot-v8.2.2
Jul 7, 2026
Merged

ryanbr merged 1 commit into
mainfrom
snapshot-v8.2.2

Conversation

@ryanbr

@ryanbr ryanbr commented Jul 7, 2026

Copy link
Copy Markdown
Owner

Adds a user-set backup time-of-day on the Backup & Sync screen (TimeChip picker, default 01:00). BackupSyncPrefs.backupMinute + setBackupMinute; delayToNextBackupMs takes a minuteOfDay; applyTimeChange re-anchors on change. Android-only (iOS backs up on next launch). Compiles; BackupSyncTest 14 pass.

The daily auto-backup time was hardcoded to 01:00. Add a user-set time-of-day:
- BackupSyncPrefs.backupMinute (minutes since midnight, default BACKUP_MINUTE_OF_DAY = 60 = 01:00,
  clamped to a valid minute) + setBackupMinute.
- delayToNextBackupMs now takes a minuteOfDay param (defaults to 1am); reschedule() reads the pref.
- applyTimeChange() cancels + reschedules so a new time re-anchors immediately (KEEP alone would
  leave the old anchor).
- BackupSyncScreen: a "Backup time" row with the reusable TimeChip (TimePicker dialog); picking a
  time saves it + re-anchors. The auto-backup blurb now says "at the time below".

Android-only: iOS has no reliable timed background scheduler (it backs up on next app launch), so a
time picker there would be misleading — left as-is. Compiles; BackupSyncTest 14 pass (added a
chosen-time test; the 1am default test still holds).
@ryanbr
ryanbr merged commit 149bbf7 into main Jul 7, 2026
@ryanbr
ryanbr deleted the snapshot-v8.2.2 branch July 7, 2026 06:03
DX23876 referenced this pull request in DX23876/noop Jul 22, 2026
Backup & Sync: configurable daily backup time (default 1am)
pipiche38 added a commit to pipiche38/noop that referenced this pull request Aug 31, 2026
Android's Oura scan callback dropped every result whose advertised name did
not recognise as an Oura ring. `ExperimentalBrand.recognise("")` is null - no
brand token is a substring of "" - so a ring advertising an empty local name
was rejected. A bonded ring commonly stops advertising one, and the callback's
`scanRecord.deviceName ?: device.name ?: ""` fallback is also empty when the
bond lives on another host, so the ring the user was most likely trying to
reconnect to was the one the wizard could not show.

The name check was never the gate: `startScan` pins SERVICE_UUID in a hardware
ScanFilter, so every result the callback sees already advertises the Oura base
service. Nothing "slipped through" for it to reject - it could only subtract
true positives. Remove it; the advertised name keeps its one real job as a
best-effort generation LABEL, corrected after connect by
`OuraRingGen.fromHardwareId`.

This closes a cross-platform divergence rather than opening one: the Apple side
has always listed on the service filter alone, and both wizards already default
a null generation (`?: GEN3` / `?? .gen3`) and label it "Oura ring". The scan
log line now matches Apple's for a nameless ring.

Both files' comments claimed a name-based drop that either does not happen
(Apple) or should not (Android); both are rewritten, since a comment describing
a filter nobody applies is how a reader restores it.

Tests: OuraNamelessRingDiscoveryTest pins the trap headlessly - a blank name
recognises as no brand, a named ring still does, and a nameless ring has no
detectable generation. The scan-callback behaviour itself needs a radio and is
validated on hardware.

Same class of bug as open_oura issue ryanbr#13 (their PR ryanbr#15); no code taken from it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019JWfRLWaFBZEENnpYpertS
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant