GalaxyBudsClient reaches the Buds over an undocumented RFCOMM channel

Two Linux packages, and only one of them autostarts

Linux gets two routes and they are not interchangeable. The Flatpak build is one universal package for every distribution, hosted on FlatHub under `me.timschneeberger.GalaxyBudsClient`. The Arch route is a binary AUR package named `galaxybudsclient-bin`, maintained by someone other than the original author.

The sandbox is where the two diverge. A Flatpak can only reach `~/.var/app/me.timschneeberger.GalaxyBudsClient/` by default, so settings and logs live under a per application directory instead of the usual home config location. Autostart is missing too: the Flatpak version does not support it unless you set it up by hand, and the app accepts `galaxybudsclient /StartMinimized` to launch silently during startup.

flatpak install me.timschneeberger.GalaxyBudsClient

On Arch the install is one line:

yay -S galaxybudsclient-bin

winget, an NSIS script, and a paid Android build

Windows has both a package manager entry point and a plain binary drop. The winget route is:

winget install timschneeb.GalaxyBudsClient

The other route is the release section, and the README asks you to read the release notes before installing rather than taking the file and finding out afterwards. The installer behind it is built from `install.nsi` at the repository root, the NSIS script that packages the Windows build.

The Android build breaks the free pattern that everything else follows. It is distributed under `me.timschneeberger.galaxybudsclient` on the Play Store and the README marks it paid, while every desktop build costs nothing. The two products live side by side in the source tree as `GalaxyBudsClient.Android/` alongside the desktop projects, but the store listing is its own distribution channel with its own release timing, which is worth remembering before you assume a desktop fix has an Android counterpart.

One solution file with four platform projects

`GalaxyBudsClient.sln` sits at the repository root next to `global.json`, which pins the SDK the solution builds against. Inside it are four platform projects: `GalaxyBudsClient.Platform.Windows`, `GalaxyBudsClient.Platform.WindowsRT`, `GalaxyBudsClient.Platform.OSX` and `GalaxyBudsClient.Platform.Linux`, with shared code in `GalaxyBudsClient.Platform/`. Two more entries matter when you read the tree: `GalaxyBudsClient.Generators/` and `GalaxyBudsClient.Tests/`.

The layout tells you how features reach you. Anything needing a Linux specific backend, a BlueZ call or an MPRIS signal, can only exist in the Linux project, so a capability described in a release note may be missing from the Windows build you installed. Having both `Platform.Windows` and `Platform.WindowsRT` means two Windows targets are maintained for the same device family, and a fix can land in one of them first.

BlueZNet, MprisClient and a Bluetooth stack are compiled into the tree

Three vendored directories sit next to the product code: `ThePBone.BlueZNet/`, `ThePBone.MprisClient/` and `InTheHand.Net.Personal.Core/`. The first two are bindings for Linux Bluetooth and for the MPRIS media interface, and the third is a vendored Bluetooth library. So on Linux the client reaches BlueZ through compiled in bindings and exposes media controls over MPRIS.

ThePBone.BlueZNet/
ThePBone.MprisClient/
InTheHand.Net.Personal.Core/

A2DP is standardized, the RFCOMM payload is not

The README explains the transport before it lists features. The earbuds expose two Bluetooth profiles: A2DP for audio streaming and control, and SPP, the Serial Port Profile, for binary streams. SPP runs over RFCOMM, and manufacturers use it to exchange configuration data, push firmware updates and send commands. A2DP is standardized and documented, while the binary data carried over RFCOMM is usually proprietary, and that gap is the real obstacle.

The documented approach was to analyze the binary stream sent by the earbuds first, then disassemble the official Galaxy Buds app for Android for more insight. Two protocol notes are committed to the repository, `GalaxyBudsRFCommProtocol.md` for the 2019 model and `Galaxy Buds Plus RFComm Protocol Notes.md` for the Plus, and both are labelled incomplete. Unusual hardware level behaviour found along the way, a firmware debug mode, an unused pairing mode and a Bluetooth key dumper, is written up separately in `GalaxyBudsPlus_HiddenDebugFeatures.md`.

The consequence for a user is plain. This client speaks to the earbuds over an interface nobody publishes, so a vendor firmware change can alter the payload without notice, and the symptom is a control that stops responding rather than an error.

Firmware downgrading is scoped to Buds+ and Buds Pro

The feature list carries the parenthesis in: firmware flashing and downgrading, for Buds+ and Buds Pro. Nothing extends that claim to the rest of the line. The older firmware binaries are not kept in this repository at all. They live in a separate archive project, `galaxy-buds-firmware-archive`, which splits the trust decision and the update decision across two places.

Firmware work is described as unfinished rather than wrapped up. At the time of writing the author was looking into modifying and reverse engineering the firmware for the Buds+, and had built two tools for that, a firmware downloader and a firmware extractor, each in its own repository. Head tracking for the Buds Pro is a third separate project. So the tooling for fetching and analysing firmware is not shipped inside the client, and matching those tools to the expectations of the build you installed is left to you.

Eleven translated READMEs, each with a warning that it drifts

The header links eleven translations in `docs/`: Simplified Chinese, Traditional Chinese, Russian, Japanese, Ukrainian, Korean, Czech, Turkish, Greek, Portuguese and Vietnamese, beside the English original. Under them sits a note that the readme files are maintained by translators, can become outdated over time, and that the English version should be relied on for the newest information.

That is an unusual thing for a project to say about its own documentation, and it changes how you read anything here. The English page is the one carrying the current Flatpak identifier, the winget command and the links to the protocol notes, so a translated page you land on first may describe a build that has moved on.

Translations are also the cheapest way to contribute. The contributing section links a wiki page for translation help, states that no programming knowledge is required, and says a custom translation can be tested without installing any development tools before a pull request is opened.

Releases are sparse while master keeps moving

Three recent tags are visible: 5.2.1 on 2026-06-07, 5.2.0 on 2026-03-05 and 5.1.2 on 2025-02-02. The first gap is thirteen months and the second is three, so the cadence is uneven. The last push to the repository is dated 2026-10-01, four months after the newest tag, which means changes land on master long before anyone can install them.

The instruction to read the release notes before installation assumes a tag exists, and a tag only appears when a release is cut. In between, the build you run is whichever one you last downloaded, and master carries no changelog to tell you what changed. There is a test project in the tree, `GalaxyBudsClient.Tests/`, but nothing published explains what it covers, so a green run is not something you can verify from outside the repository. Funding runs through `FUNDING.yml` at the root and a ko-fi page.

Editorial conclusion

Adopt GalaxyBudsClient if you want battery statistics, factory self tests, hidden debug modes and firmware rollback on a Buds+ or Buds Pro, and you accept installing a build that speaks an undocumented protocol. Skip it if you want the official vendor app's guarantees, or if your model is outside the two that support downgrading. Before installing, read the release notes as the README asks, check whether the release names your model, and on Linux decide between the Flatpak sandbox and the AUR package, because the two keep settings in different places.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. timschneeb/GalaxyBudsClient on GitHub