Re: [PATCH BlueZ 0/4] Add component batteries and Fast Pair Message Stream

Hi Matthias,

On Wed, Aug 19, 2026 at 6:32 PM Matthias Kurz <[email protected]> wrote:
>
> True wireless earbuds can report separate charge states for the left bud,
> right bud, and charging case. Battery1 currently has one fixed object per
> Device1, so BlueZ cannot expose those values without collapsing them into
> one percentage.
>
> Extend the battery core and provider API to support child Battery1 objects
> with a stable identifier, optional percentage, and optional charging state.
> The existing Battery1 object at the Device1 path remains the aggregate
> compatibility interface. Component objects and their new properties remain
> experimental.
>
> Add an experimental Fast Pair Message Stream profile which connects to the
> advertised RFCOMM service and publishes its left, right, and case battery
> updates through the new component objects. The generic unknown-level status
> bit is retained for earbuds. Treat the TWS-specific case value 0xff as
> unavailable.

Wait, what are you talking about here don't really match the Fast Pair spec:

https://developers.google.com/nearby/fast-pair/specifications/bledevice#message_stream_PSM

That seems to be BLE specific and uses L2CAP not RFCOMM.

> If the Message Stream closes while BR/EDR remains connected, invalidate the
> values and reconnect with exponential backoff. Reset the backoff only after
> a battery-producing stream remains connected for the maximum backoff
> interval, and do not retry permanent local errors. Once BR/EDR disappears,
> cancel pending work and remove the component objects. The final patch adds
> a standalone diagnostic and provider tool for interoperability testing.
>
> This was tested with Pixel Buds Pro using an ASan/UBSan build. The live
> tests covered fresh left/right/case reports, an unavailable case value,
> explicit Message Stream disconnection, remote device disconnection,
> reconnection, adapter power-down, and cancellation of a profile connection
> in progress. Component properties were invalidated or removed as
> appropriate, and the daemon reported no sanitizer failure.

I would really like some clarification on what protocol source was
used, because this doesn't seem to match anything like:

https://developers.google.com/nearby/fast-pair/specifications/extensions/batterynotification

> The full 40-test make check suite passes under ASan/UBSan. The Fast Pair
> parser tests cover payload fragmentation, a complete frame followed by a
> partial frame, invalid input, a zero-length frame, the maximum 65535-byte
> payload, unknown-level status bits, the unavailable-case sentinel, and
> reserved battery values. The Python tool compiles and its matching decoder
> was checked directly.
>
> Matthias Kurz (4):
>   battery: Add component battery objects
>   doc: Document component battery objects
>   fastpair: Add Message Stream battery profile
>   test: Add Fast Pair Message Stream tool
>
>  .gitignore                         |   1 +
>  Makefile.am                        |   8 +
>  Makefile.plugins                   |   5 +
>  Makefile.tools                     |   2 +-
>  doc/org.bluez.Battery.rst          |  35 +-
>  doc/org.bluez.BatteryProvider.rst  |  16 +
>  profiles/fastpair/fastpair.c       | 650 +++++++++++++++++++++++++++++
>  profiles/fastpair/message-stream.c | 129 ++++++
>  profiles/fastpair/message-stream.h |  42 ++
>  src/battery.c                      | 401 +++++++++++++++---
>  src/battery.h                      |   4 +
>  test/test-fastpair                 | 561 +++++++++++++++++++++++++
>  unit/test-fastpair.c               | 286 +++++++++++++
>  13 files changed, 2079 insertions(+), 61 deletions(-)
>  create mode 100644 profiles/fastpair/fastpair.c
>  create mode 100644 profiles/fastpair/message-stream.c
>  create mode 100644 profiles/fastpair/message-stream.h
>  create mode 100755 test/test-fastpair
>  create mode 100644 unit/test-fastpair.c
>
> --
> 2.55.0
>


-- 
Luiz Augusto von Dentz