fix: JRing history asks for today (#73), Connect button actually connects (#72)

[foureight84]

Closes #73, closes #72.

Two unrelated bugs that share a shape: something the app asks for is silently answered by nobody, and nothing on screen says so.

1365 tests, 0 failures. No schema changes. Not hardware-tested here — #72 is confirmed on hardware by @Albabit, #73 is not yet fixed on hardware (see the update below).

---

#73 — the JRing history request asked for the wrong day, and asked for every day at once

Part one: byte 1 is a day offset, not a count

@srinikandala's report is the good kind: it names the bytes, cites the vendor app, and comes with a prototype that was tried on hardware. It's right, and the vendor SDK settles it.

Byte 1 of 0x10 is a day offset, not a count of days. IRemoteService.getDataByDay(int type, int day) reaches BluetoothLeService.a(int, int), which writes the type into bArr[0] — 1 → 16 (0x10, activity+sleep), 2 → 22 (0x16, heart rate) — and then the day argument straight into bArr[1]. One day per call; there is no count anywhere in the path. The caller loops: DupMainActivity.onGetMultipleSportData decrements P_SYNC_HISTORY_DAY on each day's sync-end and calls getDataByDay(1, i6) again, counting down to 0.

Read as a count, our 0x10/03 asked for the day before last and 0x10/01 for yesterday. No pass ever requested today — and 0x10 is the only source of sleep, since there's no sleep-only request — so last night's sleep could not arrive however many times the app synced.

Why steps and HR hid it. Neither depends on this request for today: activity arrives on the ring's automatic 0x03 push, and makeHistoryMeasurementQueryCommand already hardcoded 16 00 — offset 0. The one request in the file that asked for today was the one that worked.

Where the wrong reading came from. The KDoc credited Gadgetbridge's triggerActivityReportByDays(). That identifier appears nowhere in decompiled-jring-offical/ — only in our own files. A citation to another project's helper isn't vendor evidence, and the count semantics arrived with it. iOS was never affected: its makeHistoryQueryCommand() is the fixed hex 1000…, i.e. offset 0 — correct for today, and it simply never backfilled.

Part two: the ring answers one history request at a time

That fix alone did not restore sleep. @srinikandala tested v2.9.1+54-rc1 on the SR08 and still saw 45 minutes against an expected 6h30. Their capture says why: 10 00, 10 01, 10 02 and 16 00 all went out inside 176 ms, with 10 02 landing between two of today's sleep packets. Four 0x11 packets arrived in total — three consecutive 15-minute blocks for today (01:15–02:00, exactly the 45 minutes displayed) and one from the previous day. The window's days were truncating each other.

The first fix recorded, in JringSyncEngine, the precise condition that would force the vendor's chain: "if a ring is ever seen truncating a day's stream when the next request lands, the vendor's chain is the fix, and it needs a sync-end signal decoded first." This is that ring, and the capture is that observation.

JringHistorySync is a port of LuckRingHistorySync — the pager already in this repo for streams that carry no end-of-transfer marker — with a second leg per day. Per day: 0x10/offset → that day's activity/sleep stream → 0x16/offset → next day. That is the vendor's own chain (getDataByDay(1, day) then (2, day)).

• Activity/sleep settles on a timer because nothing else exists. 0x10 and 0x11 are bare runs of 15 one-minute samples with nothing marking a day's end. JYouPro is in the same position and does the same thing — the 2000 ms idle timer @srinikandala documented, which is where the default comes from.
• Heart rate chains on the protocol. 0x16 subtype 0xFF already decodes to HistorySyncFinished, so that leg advances on the marker and only falls back to the timers.
• A day that answers nothing still gets its HR request. 16 00 used to be unconditional and it is the request that always worked.
• start() reports whether it began a pass, so the once-per-connection backfill gate can't be spent by a no-op — runStartup is also the ~30-minute background sync, so a second pass landing mid-backfill is routine.
• Timers are epoch-guarded and the pass is dropped on disconnect. A stale settle, or one surviving a dropped link, would land a stray 0x10 on a live stream — the same truncation from the inside.

Today still leads the window, where the vendor's countdown leaves it until last. It's the day the user opened the app to see.

#72 — Connect on the Settings card did nothing

@Albabit found this while testing #70: disconnect from Settings, tap Connect on the ring card, and nothing happens at all. No spinner, no error, no attempt.

Both buttons reconnect the same stored ring — through different entry points. userDisconnect() persists a stay-off flag so a manual Disconnect actually sticks against every auto-reconnect path (app foreground, the watchdog, RingSyncWorker, the coach runner), and connectLastKnown() honours it by returning immediately. The detail screen calls userConnect(), which clears the flag first. The hero card called connectLastKnown() — so it was suppressed by the flag in exactly the situation the button exists for.

The guard is right; the caller was wrong. The hero card and the pairing screen's "Reconnect last ring" now call userConnect(). Every genuine auto-reconnect caller is untouched and still honours it.

connectLastKnown() gains a KDoc saying it's the auto path and that a button must not call it, because its name reads exactly like what a Connect button wants.

Correction to an earlier version of this description. It claimed a second silent no-op on the same card — a "Disconnect" button drawn as enabled but wired to nothing. @Albabit pointed out no such button exists, and he's right. DeviceHeroCard has hidden the action row entirely when connected since de60096 (2026-07-06), deliberately: "the connected card is purely informational and opens Wearable settings, where Disconnect lives." Action.DISCONNECT is only produced in the connected state, so that branch was unreachable — the else -> {} was dead code, not a dead button. What this PR actually does there is make the when exhaustive and pass an onDisconnect that nothing can currently invoke: a tripwire for whoever removes the render condition later, not a fix. Disconnect on the Wearable detail screen always worked, and that's where it lives.

---

Testing and risk

./gradlew testDebugUnitTest — 1365 tests, 0 failures.

The discriminating test for the sequencing fix is the negative one: sleep frames arriving at half a settle window must not be built on top of. Ten more cover per-day ordering, the end-marker advance proven against a one-second settle window, the stall skip, the declined re-entrant start, cancel, the timer race, out-of-leg frames, and the driver wiring at both ends (ingest feeds the pager, disconnect ends it).

Behaviour change worth knowing: the first JRing connection now pulls three days of activity and three days of HR, serialized with settle gaps between them, where RC1 fired everything inside 176 ms. That's the fix working, but the first sync is visibly slower. Later passes are one day — today.

Also new and unvalidated on hardware: per-day 0x16. The SR08 has never been asked for 16 01/16 02. The vendor does it via getDataByDay(2, day), and the stall timeout covers a ring that ignores it.

Hardware status. #72: confirmed by @Albabit on v2.9.1+54-rc1 — Connect works, and Disconnect still sticks across 30+ minutes and an app restart. #73: the day-offset half is in RC1 and demonstrably not enough; the sequencing half needs a new build on @srinikandala's SR08.

🤖 Generated with Claude Code

[srinikandala]

RC1 hardware test follow-up for #73: v2.9.1+54-rc1 still shows only 45 minutes instead of the expected 6h30 on the SR08. The unredacted capture contains three 15-minute packets for today and one for yesterday; all three day requests plus HR are sent within 176 ms, with requests overlapping incoming sleep packets.

Full decoded timeline and the working prototype's sequencing are documented here: #73 (comment)

The working prototype validated explicit offsets with waiting between transfers, not the queued-together sequence in this PR. Please address the sequencing before treating #73 as resolved. The capture supports incomplete retrieval, although it does not isolate which subsequent command interrupts the ring.

[Albabit]

On the YCBT side the transfer itself looks stable, for whatever that's worth as a contrast.

I read my ring's history twice back to back with my own Python client, no app involved, and got byte-identical results:
11 frames, 1916 bytes, same sessions both times.
So on this family I'm not seeing the truncation-under-pressure your capture shows on the SR08.

Not disputing your finding, the two rings clearly behave differently.
Mentioning it only so the YCBT side isn't assumed to share the same retrieval problem.