New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 864220 link

Starred by 0 users
Status: Untriaged
Owner: ----
Cc:
█ luiz.von...@intel.com
qiyuh@chromium.org
█ mcchou@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

UUIDs in BlueZ device change semantics after service discovery

Project Member Reported by qiyuh@chromium.org, Jul 16 
UUIDs in BlueZ device could mean two different things, depending on whether service discovery is done:

1. Eir UUIDs if service discovery is not yet done
2. GATT service UUIDs if service discovery is done

This could present issues in several cases. For example, if service discovery is done, and the remote device updates its advertisement data, applications subscribing to scanning results have no ideas on the updated UUIDs.

An ideal fix is to present these UUIDs in two different fields:
i) eir_uuids
2) service_uuids

Comment 1 by luiz.von...@intel.com, Jul 18 

We have a plan to expose remote advertisements with use of LEAdvertisement1 interface: 

https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt#n16

That would be exposed on the device object path, so application will be able to distinct the UUIDs that appears on the Device1 and LEAdvertisement1, also it fixes the problem of exposing Device1 interface on non-connectable devices.

Comment 2 by dtapu...@chromium.org, Nov 1

Components: OS>Systems>Bluetooth
►

Sign in to add a comment