🩸 xDrip
What is xDrip?
If you're not in the diabetes world, you probably haven't heard of xDrip. It's an open-source Android app that reads continuous glucose monitor (CGM) data — think Dexcom G6/G7 — and gives you way more control over alerts, data sharing, and integrations than any vendor app ever will.
It genuinely saves lives — though the project rightly insists you should never rely on it as your sole source of truth. And from a developer perspective, it's a fascinating piece of software.
Why It's Awesome
The killer feature is flexibility. You get customizable alert thresholds, predictive alarms, and rich notification paths — phone, watch, followers. Caregivers can monitor remotely in real time.
It also bridges devices. When a sensor manufacturer drops support for an older transmitter or a third-party tool, xDrip fills the gap. The community moves fast — faster than any corporate release cycle.
The Developer Perspective
Under the hood, xDrip is surprisingly well-structured for a community project. Modular BLE/NFC collectors, a mature processing pipeline (smoothing, calibration, prediction), and extensive uploader/plugin hooks make it a solid integration platform.
It's a standard Android native stack with Gradle. If you're an Android engineer, you can get productive quickly. The settings and debug tooling expose internals in a way that's genuinely useful for power users and integrators.
The Downsides — Complexity and Maintenance
Here's where it gets real.
The device/OS surface is enormous. Supporting a wide range of Android versions, OEM Bluetooth quirks, and legacy devices creates an explosion of edge cases. Every OEM firmware update or Android security patch can break a collector. You fix one phone, another breaks.
There's significant technical debt. Years of feature growth and user-driven patches have produced a large, tangled codebase. Changes in one area — say, Wear OS support — ripple into places you didn't expect.
Safety vs. flexibility is a constant tension. The app isn't FDA-cleared. Community builds give users power and configurability, but maintainers have to be careful about defaults and messaging. People's health depends on this software.
And it's all volunteer-maintained. Triage and long-term refactors are expensive when nobody's getting paid.
Testing Is Really Hard
This is the part that resonates most with me as an engineer.
Device variability — different CGM firmware, phone models, Android releases, Bluetooth stacks — makes automated test coverage extremely limited. Wearables, follower networks, and cloud uploads create multi-device, multi-network scenarios that are impossible to reproduce in CI.
Hardware emulation for BLE/NFC payloads is nontrivial. Many fixes require real-world validation on multiple physical devices. There's no way around it.
As a result, maintainers have to be conservative about invasive changes. If you can't test it reliably, you can't merge it safely.
A Concrete Example — My Watch-Only G6/G7 Fork
I developed a fork that lets an Android watch connect to Dexcom G6 and with recent enhancements also to G7 sensors directly — no smartphone required! Functionally, it works and gets used by me every day. But merging it back upstream wasn't feasible.
The change required updating large parts of the mostly abandoned wear code tree and Android lifecycle handling to support standalone BLE + sensor pairing on small-form devices. That introduced new integration points and increased the number of hardware/OS permutations that need validation.
Given the maintainers' limited time and the difficulty of reliably testing across watches, phones, and multiple sensor firmware versions, they declined the merge. And honestly? I get it.
So my fork exists and demonstrates a compelling capability — watch-only CGM without a phone — but it won't land upstream because it materially raises maintenance and testing costs for the core project.
Starting From Scratch — dxconnect
The xDrip fork taught me a lot, but it also showed the limits of bolting new functionality onto a massive legacy codebase. So I started a clean-room PoC: a standalone Wear OS app written in Kotlin, built with modern tooling (Gradle 9, AGP 8.7, Kotlin 2.1), using RxAndroidBle for Bluetooth and BouncyCastle for cryptography.
G6 works. The older sensor uses a relatively straightforward BLE pairing and data exchange. Connect, authenticate, read glucose values. Done.
G7 is a different beast. Dexcom massively increased the complexity of the authentication flow. The G7 uses EC-JPAKE — a password-authenticated key exchange based on elliptic curve cryptography (secp256r1). The connection flow looks roughly like this:
- BLE Discovery — scan for the G7 sensor advertisement
- GATT Connection — connect and discover the authentication service
- Certificate Exchange (3 rounds) — each round sends a 160-byte ECC packet containing two public key points and a zero-knowledge proof. The sensor validates each round before proceeding
- Auth Request — send a token with a calculated slot byte (derived from bonding state). Get this wrong and the sensor drops you with GATT Error 19
- Challenge-Response — exchange SHA-256 hashes to prove both sides derived the same shared secret
- Bonding — trigger Android system-level BLE bonding with the sensor
Every step depends on the previous one succeeding. The ZKP validation is strict — if your elliptic curve math is off by a single byte, the sensor silently disconnects. There's no error message, no hint about what went wrong.
My PoC successfully completes the certificate exchange rounds but still fails at the authentication challenge. The slot calculation and bonding data handling have subtle dependencies on sensor firmware state that I haven't fully reverse-engineered yet. It's the kind of problem where you stare at hex dumps for hours, comparing your output byte-by-byte against xDrip's working implementation.
Work in progress. But even getting this far on a watch-only Kotlin stack felt like a win.
Closing Thoughts
xDrip is a perfect example of the power and limits of community health software. It extends access and responsiveness in ways vendor apps don't, and it truly saves lives. But that same breadth creates complexity, fragile edge cases, and daunting testing demands.
Contributions that expand device form factors — like watch-only operation — show what's possible. They also illustrate why upstream projects have to be conservative about large, hard-to-test changes. It's not about gatekeeping. It's about keeping the thing reliable for the people who depend on it.
Huge Shoutout
None of this exists without jamorham and Navid200 — the two core maintainers who have poured years of unpaid work into xDrip. They review PRs, triage bugs across hundreds of device combinations, handle safety-critical edge cases, and keep the project alive for a global community of users whose health literally depends on it.
And a big shoutout to the Nightscout community as well — the broader ecosystem of open-source CGM tools that xDrip plugs into. Nightscout pioneered the idea that people should own their own glucose data, and that spirit runs through everything here.
That's not just open-source maintenance. That's saving lives on a volunteer schedule. Massive respect.