[bluez/bluez] eda426: audio: Fix stale AVDTP connecting state

[bluez/bluez] eda426: audio: Fix stale AVDTP connecting state

[BluezTestBot]

  Branch: refs/heads/master
  Home:   https://github.com/bluez/bluez
  Commit: eda4262191ba00ab6912f54c86c2cdacc2f8b8d9
      https://github.com/bluez/bluez/commit/eda4262191ba00ab6912f54c86c2cdacc2f8b8d9
  Author: Kun Ma <mk02092022@gmail.com>
  Date:   2026-09-30 (Wed, 30 Sep 2026)

  Changed paths:
    M profiles/audio/sink.c
    M profiles/audio/source.c

  Log Message:
  -----------
  audio: Fix stale AVDTP connecting state

When a remote dual-role A2DP device reconnects autonomously, both sink
and source services transition to their respective CONNECTING states
upon AVDTP_SESSION_STATE_CONNECTING.

If the remote device only configures one direction (e.g. initiating a
stream from remote Source to local Sink), the unused direction's state
remains stuck in CONNECTING even after the underlying AVDTP session has
reached AVDTP_SESSION_STATE_CONNECTED.

Subsequently, when policy or userspace attempts to initiate audio
playback (e.g. via sink_connect() or source_connect()), the call fails
immediately with -EBUSY due to this stale CONNECTING state.

Fix this by only returning -EBUSY if the underlying AVDTP session is
actually still in AVDTP_SESSION_STATE_CONNECTING. In addition, check if
a stream already exists on that service to prevent concurrent stream
allocations while the session is connected.

Link: https://github.com/bluez/bluez/issues/2381


  Commit: a086d234e503daf6260fec61b7f4fd8f1028e165
      https://github.com/bluez/bluez/commit/a086d234e503daf6260fec61b7f4fd8f1028e165
  Author: Seonggon Cho <jmsmg1@me.com>
  Date:   2026-09-30 (Wed, 30 Sep 2026)

  Changed paths:
    M tools/mpris-proxy.c

  Log Message:
  -----------
  mpris-proxy: Line-buffer stdout

mpris-proxy reports adapter and player changes with printf() but never
flushes stdout. When it runs as a service (tools/mpris-proxy.service)
stdout is a pipe to the journal, so glibc fully buffers it and nothing
is written until 4 KiB have accumulated or the process exits.

On a system whose Bluetooth adapter went away and came back every two
minutes, the "Bluetooth Adapter /org/bluez/hci0 removed" and "... found"
messages reached the journal in bursts of exactly 100 lines (about
4096 bytes), all carrying the timestamp of the flush rather than of the
event, i.e. up to about 80 minutes late.

Set stdout to line buffered at startup, as bt_shell_init() already does,
so every message reaches the journal with an accurate timestamp.

Assisted-by: Claude:claude-fable-5-1


  Commit: 05870ea62923caa4a7de233e733dea8bf77223d7
      https://github.com/bluez/bluez/commit/05870ea62923caa4a7de233e733dea8bf77223d7
  Author: Cheng Jiang <cheng.jiang@oss.qualcomm.com>
  Date:   2026-09-30 (Wed, 30 Sep 2026)

  Changed paths:
    M profiles/ranging/rap_hci.c
    M src/shared/rap.c

  Log Message:
  -----------
  ranging: Route CS subevent results by connection and configuration

bt_rap_attach_hci() allocates a state machine per device and registers the
CS subevent handlers of each one on the shared bt_hci. LE Meta subevents
are dispatched with queue_foreach() over every registered handler, so each
CS Subevent Result is delivered to all of them, not only to the device the
event belongs to.

The Subevent Result and Subevent Result Continue handlers then passed their
own sm->rap on without checking which connection reported the event, unlike
every other handler in rap_hci.c, which resolves it with
find_mapping_by_handle() and returns when the connection is not its own.
The Connection_Handle was parsed into the event and never read again, in
rap_hci.c or in shared/rap.c.

With two CS connections up, one set of ranging data was therefore consumed
by both sessions and sent out over both peers' RAS characteristics. Resolve
the mapping and drop the subevent when the connection is not tracked.

handle_local_subevent_result() and parse_cs_local_initiator_data() also
took a config_id they never checked against the tracked one, so subevents
belonging to a second CS configuration on the same connection were
appended to the procedure of the first. Ignore a subevent whose config_id
does not match the tracker, once the tracker has one.

Assisted-by: Claude:claude-opus-4.8


  Commit: 549f3d50686bbf18f01b949a913ddd10cb6e8b5c
      https://github.com/bluez/bluez/commit/549f3d50686bbf18f01b949a913ddd10cb6e8b5c
  Author: Jinwang Li <jinwang.li@oss.qualcomm.com>
  Date:   2026-09-30 (Wed, 30 Sep 2026)

  Changed paths:
    M obexd/plugins/phonebook-dummy.c

  Log Message:
  -----------
  obexd: Fix FILE* leak in phonebook-dummy

fdopen(fd, "r") transfers ownership of fd to the FILE stream, but the
loop was calling close(fd) directly instead of fclose(fp), leaking the
FILE structure and its stdio buffer on every vCard read. Also handle
fdopen() failure, which was previously unchecked.


Compare: https://github.com/bluez/bluez/compare/dbc6102ccdee...549f3d50686b

To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications