A patented BLE communication layer for Android

Context

A first-of-its-kind connected consumer device needed an Android app built from scratch on a compressed timeline: device pairing and control, usage tracking, and over-the-air firmware updates. Everything the product did depended on a radio link that is unreliable by design.

Why the obvious approach failed

Android's stock BLE framework is callback-driven. Every operation — connect, discover services, read, write, subscribe — completes on a callback, and the platform permits only one outstanding GATT operation at a time. The conventional answers each fail in their own way: chaining callbacks produces nesting that becomes unreadable at the third level and untestable at the fourth; a hand-rolled state machine wrapper moves the complexity rather than removing it, and every new operation means a new set of states and transitions; queueing operations behind a synchronous facade blocks the calling thread, which on Android means blocking the main thread or inventing a threading model per feature. None of them survives real-world connection churn, where a device wanders out of range mid-operation and every in-flight callback has to be reasoned about individually.

The mechanism

The layer exposes BLE operations as suspending functions. A caller writes connect, then authenticate, then write — sequentially, in the order the protocol requires — and the layer guarantees that each completes before the next begins. The concurrency is real; only the callback plumbing disappears.

Underneath, operations are serialized through a queue that owns the single-outstanding-operation constraint the platform imposes. The queue is the only thing that has to know about that rule, so no feature written on top of the layer can violate it.

Three candidate API designs were evaluated during development; all three are documented in the patent as FIG. 5A, 5B and 5C. The suspending-call design won because it makes the correct sequencing the default rather than something each caller must remember, and because cancellation composes — when a caller goes away, the in-flight operation unwinds with it instead of completing into nothing.

The application was built on top of that foundation: pairing and device control, usage tracking, and firmware updates delivered over the air. A third-party identity verification flow — driver's licence capture — gated device activation, so a hardware unlock depended on the result of a cloud verification round trip.

The hard part

Reestablishing a connection that drops mid-operation. A BLE link fails constantly and unremarkably — the user walks into another room — and when it does, there is in-flight operation state on both sides of a radio link that no longer exists. Reconnecting is the easy half; the hard half is deciding what the pending operation meant. Retrying blindly can repeat a write the peripheral already applied. Failing everything upward makes the app fragile for what is, physically, a normal event. The layer handles connection loss and reestablishment as a first-class concern rather than an error path, so that operation state is resolved deterministically rather than per-feature. The patent documents this flow as FIG. 7.

Results

The app shipped from zero to production on the compressed timeline, and the communication layer was granted as US Patent 10,820,358 on 27 October 2020, with four named inventors. Stated honestly: a patent is a claim of novelty examined by the USPTO, not a measurement of production reliability, and the field-reliability numbers that would substantiate the engineering claim belong to the company and are not mine to publish. What is externally verifiable is the filing itself — the mechanism, the three candidate designs, and the connection-management flow are all in the public record and can be read in full.

What I'd do differently

I would have pushed to open-source the layer, separated from anything product-specific. The problem it solves is not proprietary — every Android team talking to hardware rebuilds some version of it — and a public implementation would have been worth more to the ecosystem, and to the team, than a private one.