Repository navigation
Release readiness: Android compatibility, stable 0.1, and external TestFlight #34
Description
Goal
Ship the next verified 0.1.x build as a real, non-prerelease GitHub release with a signed Android APK and an externally testable iOS build. First validate the Android compatibility fix through a private release-mode candidate; do not create another public prerelease just for diagnosis.
Guardrails
- Do not publish tester contact details, screenshots, sensor/device identifiers, health data, credentials, profiles, certificates, or private diagnostics.
- Do not ask testers to uninstall, unpair, or reset an active sensor unless a separately reviewed recovery procedure requires it.
- Product-facing release notes describe user-visible changes only.
Now
- Fix the already-bonded Android session path. One real device completes Android pairing but OpenGlucose remains at
Connectingwith no sensor details. Capture identifier-free stage/failure evidence across service discovery, notification subscription, vendor handshake, and baseline reads; reproduce an already-bonded reconnect; add deterministic regression coverage; verify on both the affected and known-good phones. - Build a private Android candidate. Use release mode, the existing package/signing lineage, and a fresh build code. Verify package, version, signer, and digest. Deliver privately as an in-place update and record the sanitized result. Do not attach it to a GitHub Release or public workflow artifact.
Stable 0.1 release blockers
- Record stable-release semantics. GitHub already has
v0.1.0andv0.1.1as prereleases, so those tags cannot represent new bytes. Select the next unusedv0.1.xversion/build and publish it as non-prerelease only after the candidate passes. Keep historical tags unless a separate destructive-cleanup decision is approved. - Make release automation support a real release. The current Android lane and draft TestFlight lane require
prerelease == true; update and test both so an approved non-prerelease can launch the two platform lanes without creating another public prerelease. - Land and configure the protected TestFlight workflow. Merge #33 after review, then configure its protected release environment and durable private state store under owner approval. Prove configuration with fail-closed preflight evidence before publishing a release.
- Resolve export compliance truthfully. Review the cryptography shipped by the app and dependencies, have the Apple Account Holder make the required determination, and store the decision/evidence privately before external beta review or notification.
- Upload and approve the next iOS build. No iOS
0.1.1 (19)was uploaded. Use the next verified version/build, confirm processing and exact audience, submit Beta App Review, and notify only after approval. - Choose and restore the external tester path. Decide between a controlled invite-only group and a public join link. Configure the workflow and audience consistently, attach the approved build, set usable capacity/invitations, and verify join + install with a new tester.
- Close external-release device controls. Record redacted physical-device evidence for data handling, active lock-screen redaction, release logging, and the critical sensor journey required by the repository control register.
Product follow-up
- Verify the complete warmup lifecycle. A phone entering warmup is useful evidence but does not prove countdown, transition to ready, or reading availability. Capture expected behavior, verify warmup-to-ready on hardware, and add a regression test.
- Raise the iOS deployment floor before Apple’s deadline. The current iOS 14 warning is not the present upload blocker; schedule iOS 15 migration, compatibility documentation, and CI/device verification before Spring 2027.
Operational tracking
- Reconcile the checked-in backlog. All 43 existing
.backlog/tasksentries still reportTo Do, including features already shipped. Audit each against its acceptance criteria, markDone/In Progress/To Doaccurately, remove stale branch notes, and add the release/compatibility work above. - Keep private-chat follow-ups sanitized. Review tester conversations for additional action items, but record only technical summaries in this public repository.
Current evidence
- v0.1.0 and v0.1.1 are both public prereleases.
- #33 is draft, cleanly mergeable, and its current CI/security checks pass; live release infrastructure is intentionally not enabled by the PR.
- #32 addressed initial Android bonding but does not yet have passing evidence for the newly reported already-bonded session path.
Activity
raynman1 commentedon Aug 15, 2026
Private Android validation candidate built and delivered (not published as a GitHub Release).
0.1.1-ronell.1 (20)4ba534f825c4d2101a1bcc61230a85c82b53958145ce00819246642f91bce1617235943199370e20a9ab64d8d90d1d8fe8ad831aHardware validation remains pending. Do not mark the compatibility item complete until the affected phone successfully reaches a verified sensor session (or returns a sanitized failure stage).
raynman1 commentedon Aug 15, 2026
Hardware result for private candidate
0.1.1-ronell.1 (20): failed on the affected Android device.Observed after selecting the already-paired sensor:
Connecting.The sensor disconnected. Keep the phone close and try again.--, and history remains at zero.This is not a warm-up state and does not close the compatibility task. The candidate did improve failure presentation but did not establish a verified vendor session. Next step: capture an identifier-free setup phase/operation/diagnostic code in a private diagnostic build, then patch the exact failing boundary. No public release should be created for this iteration.
shroominic commentedon Aug 15, 2026
Private candidate round 2 is now in hardware validation.
Copy support codeaction emits only a closed setup phase plus sanitized BLE category/operation/code; it excludes identifiers, native text, readings, and raw data.0.1.1-ronell.2 (21)was delivered privately as an in-place update. It was not published as a GitHub Release or public artifact.Awaiting the affected-phone result. If setup still fails, the copied
OGSUP1line will identify the exact phase for the next fix.shroominic commentedon Sep 1, 2026
Unverified field observation: intermittent disconnect
A participant reported that the sensor “sometimes disconnected” and that reconnecting in the app was unclear. This is not yet a reproducible defect: the interview did not capture the platform, app version, phone/OS, exact state, frequency, message, support code, or recovery result.
Before opening a separate runtime-reconnect bug, collect:
Android setup recovery from PR #52 and PR #55 shipped in v0.1.3 and is present in v0.1.6. If a verified session on a current build fails to recover, open a focused runtime-reconnect bug. Recovery must preserve the bond, active session, and stored readings.