Repository navigation
docs: fix two remaining dead NoopApp/noop links (#60 follow-up) - #61
Merged
Merged
Conversation
Two live-dead links to the deleted upstream repo that the #60 sweep missed: - The in-app "What's New" AltStore-source instruction pointed at raw.githubusercontent.com/NoopApp/noop/main/altstore-source.json (404). The live manifest is at ryanbr/noop; repoint both platforms' changelog entry. - tools/linux-capture/README.md linked issue #194 at NoopApp/noop (404) → ryanbr. Targeted at those exact URLs only — the historical 'NOOP is back on GitHub' changelog card (which narrates a past NoopApp move) is deliberately left as-is. Android compiles.
ryanbr
pushed a commit
that referenced
this pull request
Jul 10, 2026
…attery + manual controls (#173) * fix(ble): reliable 5/MG reconnect + live battery push Reconnect after an involuntary drop used connectToDevice(autoConnect=true), the passive mode that waits for a fresh advertisement or connection-complete event. A 5/MG the OS still holds bonded and ACL-connected never re-emits that event, so the reconnect hangs, while app-start connects instantly through the autoConnect=false fast path. Use the fast direct path for the first two reconnect attempts, then fall back to autoConnect=true from the third attempt for a strap that is genuinely out of range (keeps the #61 return-to-range behaviour). Battery on 5/MG comes only from a 0x2A19 read (refreshBattery), which was invoked only from the Live screen, and the keep-alive battery poll was WHOOP4-only, so the ring refreshed only on a manual Body > Health > Sync. Poll 0x2A19 in the keep-alive for 5/MG too (every ~60s, advancing keepAliveTick for both families) and read it once after the connect handshake so it populates on connect. * feat(ui): manual Reconnect/Disconnect in the device menu Add Reconnect and Disconnect actions to the WHOOP device's overflow menu (the same menu as Remove), so there is a one-tap manual recovery when the automatic reconnect is stuck. Reconnect calls AppViewModel.connect(), the same active, direct (autoConnect=false) path onboarding uses, which is why re-running setup always reconnects while a passive auto-reconnect can hang. WHOOP only; shown first in the menu; Disconnect replaces it while connected. * fix(ble): attach to an OS-connected WHOOP without a scan (getConnectedDevices) The BLE client was scan-only: it could reach a WHOOP 5/MG only by scanning for its advertisement. Once another app (the official WHOOP app) holds the band it stops advertising, so a manual connect, the add-device search and the automatic reconnect all found nothing and looped on "Scanning for WHOOP...". Android multiplexes one ACL across GATT clients, so the band is still returned by getConnectedDevices even when it is not advertising, and a client can attach to it directly. connect() and the add-device search now try getConnectedDevices first, then a bonded-but-not-connected direct connect, then the scan. Both attach helpers match only a 5/MG strap by name (a WHOOP 4 falls through to the scan) and pin selectedModel to 5/MG on a hit, so a fresh install that still defaults to WHOOP 4.0 attaches to a connected 5/MG instead of scanning for the wrong family; the family is resolved from the discovered GATT services. Also polished the reconnect and battery comments to be implementation-neutral.
DX23876
pushed a commit
to DX23876/noop
that referenced
this pull request
Jul 22, 2026
docs: fix two remaining dead NoopApp/noop links (ryanbr#60 follow-up)
DX23876
pushed a commit
to DX23876/noop
that referenced
this pull request
Jul 22, 2026
…attery + manual controls (ryanbr#173) * fix(ble): reliable 5/MG reconnect + live battery push Reconnect after an involuntary drop used connectToDevice(autoConnect=true), the passive mode that waits for a fresh advertisement or connection-complete event. A 5/MG the OS still holds bonded and ACL-connected never re-emits that event, so the reconnect hangs, while app-start connects instantly through the autoConnect=false fast path. Use the fast direct path for the first two reconnect attempts, then fall back to autoConnect=true from the third attempt for a strap that is genuinely out of range (keeps the ryanbr#61 return-to-range behaviour). Battery on 5/MG comes only from a 0x2A19 read (refreshBattery), which was invoked only from the Live screen, and the keep-alive battery poll was WHOOP4-only, so the ring refreshed only on a manual Body > Health > Sync. Poll 0x2A19 in the keep-alive for 5/MG too (every ~60s, advancing keepAliveTick for both families) and read it once after the connect handshake so it populates on connect. * feat(ui): manual Reconnect/Disconnect in the device menu Add Reconnect and Disconnect actions to the WHOOP device's overflow menu (the same menu as Remove), so there is a one-tap manual recovery when the automatic reconnect is stuck. Reconnect calls AppViewModel.connect(), the same active, direct (autoConnect=false) path onboarding uses, which is why re-running setup always reconnects while a passive auto-reconnect can hang. WHOOP only; shown first in the menu; Disconnect replaces it while connected. * fix(ble): attach to an OS-connected WHOOP without a scan (getConnectedDevices) The BLE client was scan-only: it could reach a WHOOP 5/MG only by scanning for its advertisement. Once another app (the official WHOOP app) holds the band it stops advertising, so a manual connect, the add-device search and the automatic reconnect all found nothing and looped on "Scanning for WHOOP...". Android multiplexes one ACL across GATT clients, so the band is still returned by getConnectedDevices even when it is not advertising, and a client can attach to it directly. connect() and the add-device search now try getConnectedDevices first, then a bonded-but-not-connected direct connect, then the scan. Both attach helpers match only a 5/MG strap by name (a WHOOP 4 falls through to the scan) and pin selectedModel to 5/MG on a hit, so a fresh install that still defaults to WHOOP 4.0 attaches to a connected 5/MG instead of scanning for the wrong family; the family is resolved from the discovered GATT services. Also polished the reconnect and battery comments to be implementation-neutral.
simoncad7
pushed a commit
to simoncad7/noop
that referenced
this pull request
Aug 17, 2026
…attery + manual controls (ryanbr#173) * fix(ble): reliable 5/MG reconnect + live battery push Reconnect after an involuntary drop used connectToDevice(autoConnect=true), the passive mode that waits for a fresh advertisement or connection-complete event. A 5/MG the OS still holds bonded and ACL-connected never re-emits that event, so the reconnect hangs, while app-start connects instantly through the autoConnect=false fast path. Use the fast direct path for the first two reconnect attempts, then fall back to autoConnect=true from the third attempt for a strap that is genuinely out of range (keeps the ryanbr#61 return-to-range behaviour). Battery on 5/MG comes only from a 0x2A19 read (refreshBattery), which was invoked only from the Live screen, and the keep-alive battery poll was WHOOP4-only, so the ring refreshed only on a manual Body > Health > Sync. Poll 0x2A19 in the keep-alive for 5/MG too (every ~60s, advancing keepAliveTick for both families) and read it once after the connect handshake so it populates on connect. * feat(ui): manual Reconnect/Disconnect in the device menu Add Reconnect and Disconnect actions to the WHOOP device's overflow menu (the same menu as Remove), so there is a one-tap manual recovery when the automatic reconnect is stuck. Reconnect calls AppViewModel.connect(), the same active, direct (autoConnect=false) path onboarding uses, which is why re-running setup always reconnects while a passive auto-reconnect can hang. WHOOP only; shown first in the menu; Disconnect replaces it while connected. * fix(ble): attach to an OS-connected WHOOP without a scan (getConnectedDevices) The BLE client was scan-only: it could reach a WHOOP 5/MG only by scanning for its advertisement. Once another app (the official WHOOP app) holds the band it stops advertising, so a manual connect, the add-device search and the automatic reconnect all found nothing and looped on "Scanning for WHOOP...". Android multiplexes one ACL across GATT clients, so the band is still returned by getConnectedDevices even when it is not advertising, and a client can attach to it directly. connect() and the add-device search now try getConnectedDevices first, then a bonded-but-not-connected direct connect, then the scan. Both attach helpers match only a 5/MG strap by name (a WHOOP 4 falls through to the scan) and pin selectedModel to 5/MG on a hit, so a fresh install that still defaults to WHOOP 4.0 attaches to a connected 5/MG instead of scanning for the wrong family; the family is resolved from the discovered GATT services. Also polished the reconnect and battery comments to be implementation-neutral.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #60 — two live-dead links to the deleted upstream repo that the sweep missed (both return 404 now; the ryanbr equivalents resolve):
AppChangelog.swift+AppChangelog.kt) — the changelog entry instructs users to addraw.githubusercontent.com/NoopApp/noop/main/altstore-source.json, a dead URL shipped in the app. Repointed toryanbr/noop(the live manifest). Both platforms.tools/linux-capture/README.md— the#194link pointed atgithub.com/NoopApp/noop/issues/194→ryanbr/noop.Targeted at those exact URLs only. The historical "NOOP is back on GitHub" changelog card — which narrates a past move to NoopApp — is deliberately left as-is (it's a dated record; #54's edit of it was also malformed). Android compiles clean; the Swift change is a string-literal swap.
Closes out the link canonicalization alongside #60.