It’s been awhile since the last BlueZ release, but now we finally have another one out. Most of the fixes are LE (specifically GATT) related, however a some other areas are affected as well. Feature-wise, there’s a new MIDI plugin and support for using single-mode (LE-only) controllers that lack a public address (therefore necessitating the use of a static random identity address). E.g. any nRF5x controller running a MyNewt or Zephyr based firmware falls into this category.
Archive for the ‘Release’ Category.
This is almost purely a bug-fix release with fixes to HoG, ATT and PAN. There’s also a fix for a regression in 5.42 that caused connection failures for external profiles like OBEX. Feature-wise there’s one notable addition: LE privacy. By enabling this in main.conf it’s now possible to make BlueZ generate a local Identity Resolving Key (IRK) and use Resolvable Private Addresses (RPAs) for itself.
The major API change with this release is that the GATT D-Bus API is no longer marked as experimental.This should hopefully encourage the creation of more applications using it. Feature-wise, btmon received support for decoding full mgmt message traces – a feature that is available in the bluetooth-next kernel tree, i.e. on its way to the 4.9 kernel release. In addition to these changes, this release contains also fixes in areas such as PBAP, transport selection (BR/EDR vs LE), ATT and A2DP.
BlueZ 5.41 is purely a bug-fix release targeting areas such as GATT, AVRCP, OBEX and device discovery filters. The GATT D-Bus API is now starting to be stable enough that this will likely be the last release where it is flagged as experimental.
This is mostly a bug fix release fixing issues with GATT, paired devices and connection handling (particularly for accepting connections through the Profile D-Bus interface).
One new feature is the ability to use btmon for reading HCI logs from a TTY device. Right now the creation of this kind of logs is available with Zephyr in the form of a special console logging mode (more information available here). The format of the protocol is a slight modification of what btmon normally receives from the kernel monitor sockets, and is documented in doc/btsnoop.txt).
This is almost entirely a bug fix release with important fixes to GATT, HoG, AVRCP & A2DP. It is recommended to upgrade if you were previously using 5.38.
This release has lots of updates and fixes to the GATT D-Bus API. It should be working considerably better now. A key change to the GATT D-Bus API is that it is now fully conforming to the word of the D-Bus Object Manager specification. Instead of registering each service individually with an Object Manager interface per service path, all application services are now grouped together through a single RegisterApplication call. The details can be found in doc/gatt-api.txt. Besides the D-Bus API change there are also numerous fixes to GATT functionality in general.
Other areas that received fixes in this release are OBEX, AVRCP and 128-bit UUID handling. Feature-wise there isn’t anything groundbreaking, but a notable update is support for the Start Limited Discovery command in the btmgmt tool (this feature debuted with the 4.5 kernel release).
Here’s the traditional X-mas/end-of-year release of BlueZ. Most of the changes are bug fixes, targeting areas such as GATT and external profile registration. Another large chunk of changes is refactoring to use the same implementation for Android and non-Android LE profiles (e.g. HoG). With this release btattach (the successor to hciattach) finally has a manual page and will get installed by default. There’s also a new feature that will become available together with the Linux kernel 4.5 version: support for a new logging channel which lets btmon interleave HCI and bluetoothd logs into the same output. For those wanting to experiment with this feature already now, you can find it e.g. in the bluetooth-next kernel tree. One minor but noteworthy change is that the default IO capability of agents (used for pairing) has changed from “DisplayYesNo” to “KeyboardDisplay”. This is an LE-specific capability which makes more sense on most systems than “DisplayYesNo”. On BR/EDR connections “KeyboardDisplay” gets automatically translated to “DisplayYesNo” (so no change in behavior there).