RWfit ring family (#130), rebuilt from the vendor app

[foureight84]

Rebuild of iOS #130 (RWfit ring family) from the vendor app.

Why this is a rebuild

The first version of this driver landed in PR #45 and was backed out (4027235) before that PR merged. It hadn't come from the vendor app at all — every wire-level constant was invented, so none of it could ever have talked to a real ring:

	vendor app	backed-out version
write / notify characteristics	b002 / b003	a002 / a003
legacy frame	7E 01 cmd flags dataLen serHi serLo xor	7E len cmd payload xor
deviceInfo / battery / setTime	0x00 / 0x01 / 0x21	0x01 / 0x02 / 0x03
history	0xA0 manifest + 0xA1–0xA7	invented 0x10 / 0x11
unbind	0x44	0xFF
0xFE/0xFF ACK handshake	mandatory	absent
recognition	advertisement only	name.startsWith("RW")

Full detail in docs/ios-sync.md § "RWfit (#130) — backed out".

This version

Everything is read out of decompiled-rwfit-official/ (package com.rw.revivalfit) and cited to the file it came from, per the root AGENTS.md rule that the vendor app beats iOS parity. iOS's RWfitProtocol.swift cites the same decompile, and every claim it makes was re-derived rather than trusted — it checks out, with one exception below.

Things the extraction turned up that iOS's summary didn't carry:

• Battery percent is payload byte 2, not byte 0 (PowerBean is [lowPowerFlag, powerStatus, percent]). Reading byte 0 gets a boolean, which is why the old driver reported every ring as 0 % or 1 %.
• setTime is not a shared encoder — legacy sends the full four-digit year as a BE u16 (p.java u()), JieLi sends year - 2000 in one byte (p.java v()). Sharing it would set the ring's clock ~2000 years out, and every history timestamp with it.
• Temperature is offset-encoded: °C = (raw + 200) / 10.
• Sleep stage types confirmed from the vendor's own aggregation (s1.java:1636-1645, which sums them into wakeupCount/light/deep/REM) rather than guessed from the byte values: 0 awake, 1 light, 2 deep, 3 REM.
• A vendor timestamp bug, replicated deliberately. The correction uses useDaylightTime() — "does this zone ever observe DST" — not inDaylightTime(date), so the vendor is an hour out for half the year in DST zones. Matched exactly: being "correct" here would put us an hour off what the ring and the vendor app agree on.

One iOS error found

iOS records the JieLi unbind triple as {0x03, 0x01, 0x30}. The vendor's table (y5/c.java) has no such entry — the only other group-3 0x20 triple is {0x03, 0x02, 0x20}. Left as JieLi.UNBIND_UNCONFIRMED and not sent: guessing inside the bind group risks re-binding or factory-resetting someone's ring. Worth an upstream issue on PulseLoopiOS.

Scope

Complete — legacy 0x7E: framing, serials, XOR, the mandatory 0xFE/0xFF ACK handshake with the vendor's ack-before-parse ordering, multi-packet reassembly, all six history streams, battery, and the manifest-gated cascade.

Partial — JieLi 0xAB: framing, handshake, battery, time sync and the ACK discipline work. The 05-group history bodies have their own per-type layouts that have not been extracted, so the sync engine does not request history on a JieLi link and the driver logs those frames rather than guessing at them.

Not done, and marked as such rather than faked:

• Feature bitmap (x5/b.java i() → SupportMenuBean) isn't decoded, so bitmapGatedCapabilities is declared but nothing grants from it yet. Manual/realtime measurement stays ungranted — the vendor app has no legacy on-demand measurement command at all, so a Measure button on a 0x7E link could only ever time out.
• Step intraday buckets: the per-item index can't be placed on a wall clock without the ring's bucket width, which the vendor never states. Day totals only.

Blast radius outside the RWfit* files

• WearableDriver gains servicesDiscovered(serviceUUIDs) with a no-op default. RWfit needs it because the wire framing isn't in the advertisement — the vendor picks it post-connect from sibling services (r5/b.java onServicesDiscovered).
• RingBLEClient.onServicesDiscovered calls it, before any GATT work.
• RingDeviceType.RWFIT, a WearableModel catalog entry (empty advertisedNamePatterns — recognition is advertisement-only, on purpose), the coordinator registration, and a DeviceHeroCard arm.
• testOptions.unitTests.isReturnDefaultValues = true, so JVM tests can cover code that logs. Without it android.util.Log throws "not mocked", which would mean choosing between testing the ring drivers and being able to diagnose them in the field.

Testing

49 new unit tests — RWfitCodecTest (20), RWfitDecoderTest (16), RWfitDriverTest (13) — asserting vendor byte layouts rather than the implementation. Every assertion in the codec and decoder files fails against the backed-out driver. Suite 812 → 866, all passing; debug APK builds.

⚠️ No hardware validation

Nothing here has talked to a real RWfit ring. The tests pin the wire format to the vendor's own bytes, which is the strongest check available without a device, but it is not the same thing. Recommend shipping this in its own release rather than folded into 2.5.0, so any connect regression report has one unambiguous suspect.