We should do so if it implements something that a client of device/bluetooth needs. What is that client feature? Please mark this issue blocking that feature's issue. 

Also please search for past issues before opening new ones:


 http://crbug.com/546613 
 http://crbug.com/546614 

Re #1

It's for ARC++. b/28250518

FYI, Here is the Android code that parse the Advertising Data.
https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r46/core/java/android/bluetooth/le/ScanRecord.java#175

Re #2
Will do.
However this is not a completely duplicate bug. Android also want the Advertise Flag defined in Bluetooth Core Supplementary Spec v6 Chapter 1.3.

Deleted: flag_data_type.png 34.7 KB

	flag_data_type.png 34.7 KB View Download

I just found out today that Bluez also don't plumb up the service data.

Yup. That's:  http://crbug.com/546613 

 Issue 546613  has been merged into this issue.

 Issue 546614  has been merged into this issue.

It doesn't look like the flags get sent up to BlueZ (at least not in that format). We can reconstruct some of that data based on device data, but that is beyond the scope of the bug. Please file a separate bug to track getting the flags values of an advertisement for a device.

Opal, is this needed for M-54?
If so, what depends on it? ARC++?

ARC++ need this.

Now we send advertise data to Android without manufacture data and service data.
BlueZ should expose those to allow us to send every thing to Android.

Both manufacturer and service data are exposed:

https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/device-api.txt

Perhaps those are not enabled? Also in order to detect beacons you need to use SetDiscoveryFilter:

https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/adapter-api.txt

But ultimately Im not sure this will work out well since the Android stack is logically split between HAL and java layers. A lot of times Android does things in java where BlueZ does automatically, this happens for example with GATT subscription to notifications/indications which bluetoothd deals with but Android HAL only have primitives to Read/Write attributes.

manufacturer and service data are indeed exposed by Bluez but not yet plumbed into Chrome: https://chromium.googlesource.com/chromium/src/+/004c048627a230d2a77505473892a4388c38376f/device/bluetooth/dbus/bluetooth_device_client.cc#180

As a side note, I actually wonder what service data are actually read in ARC++ bridge: https://chromium.googlesource.com/chromium/src/+/7a8399b1e00b3cd796396021c99472ef43d5f7a7/components/arc/bluetooth/arc_bluetooth_bridge.cc#1649

I can't see the Advertise Flag defined in BlueZ though being exposed.
Is that something BlueZ folks would be able to do?

The flags are not exposed since BlueZ deal with that already as it is most about GAP and not profile specific but perhaps it makes sense to give hint to applications, specially when doing filtered discovery it could be useful to distinct if the device is discoverable/connectable or not. But we got another proposal on the way:

http://www.spinics.net/lists/linux-bluetooth/msg66818.html

Luiz, the proposal that you linked. How does that handle dual-mode devices?

That is adding dedicated interfaces per bearer, org.bluez.DeviceLE1 to control LE and org.bluez.DeviceBR1 to control BR/EDR. There seems to be a consensus among BlueZ developers that in order to handle dual-mode devices properly we will require a split in handling of the bearers, what we haven't agreed yet is the interfaces names and some small details. Note that org.bluez.Device1 will probably stay for a while so we wouldn't break the existing APIs.

Gotcha - I'll keep a lookout on the list on how dual-mode devices are handled. I like the concept of breaking devices into their bearers but I am not sure if it is the best idea given that we have to live with dual-mode devices and their quirks. In fact, it seems that an increasing number of devices are deciding to go dual-mode.

This is a trend we should expect to continue till well after 5.0 is released.

I'm working on this now.

This is require by fitbit app.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0dd82b1c975662a10f34a53b3df56d98526b36d0

commit 0dd82b1c975662a10f34a53b3df56d98526b36d0
Author: puthik <puthik@chromium.org>
Date: Thu Oct 06 05:03:03 2016

bluetooth: Expose service data from BlueZ

BlueZ exposed Bluetooth device's ServiceData as a{sv} property[1]
where the dict value variant is an array of byte.

This CL exposes that to upper layer by
- Add support to map<string, vector<uint8_t>> in dbus::Property
- Add new service_data property in BluetoothDeviceClient
- Implement GetServiceDataUUIDs() and GetServiceDataForUUID()
  in BluetoothDeviceBlueZ
- Fix misc style issues in original code to make linter happy

[1] http://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/device.c#n2551

BUG= 618442 , 653310 ,b:28670943
TEST=Manually tested.

Review-Url: https://codereview.chromium.org/2369423003
Cr-Commit-Position: refs/heads/master@{#423434}

[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/dbus/property.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/dbus/property.h
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/dbus/property_unittest.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluetooth_device.h
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluez/bluetooth_adapter_bluez.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluez/bluetooth_bluez_unittest.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluez/bluetooth_device_bluez.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluez/bluetooth_device_bluez.h
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/dbus/bluetooth_device_client.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/dbus/bluetooth_device_client.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/system_api/+/4b7af42bdb34a748fe348c25351d8ce97385c309

commit 4b7af42bdb34a748fe348c25351d8ce97385c309
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Thu Oct 13 21:46:02 2016

service_constants: Add Flags property to bluetooth_device

Add the name of the Advertising Data Flags property for remote
devices in BlueZ.

BUG= chromium:618442 
TEST=emerge system_api

Change-Id: I870dd7cd0253fb8474138bd305faf69d6e5661de
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/398418
Reviewed-by: Rahul Chaturvedi <rkc@chromium.org>

[modify] https://crrev.com/4b7af42bdb34a748fe348c25351d8ce97385c309/dbus/service_constants.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/632e800718e4ad0ebe09951c36d4329403539799

commit 632e800718e4ad0ebe09951c36d4329403539799
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Thu Oct 20 02:03:37 2016

UPSTREAM: doc/device-api: Add AdvertisingFlags

This exposed Advertising Flags to BlueZ Device API

BUG= chromium:618442 
TEST=ARC device can see Bluetooth Flag nRF Connect App

Change-Id: I1f9c6f009d5eeb80b99b248f7e813e44f9e5dd52
Reviewed-on: https://chromium-review.googlesource.com/402212
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
Trybot-Ready: Miao-chen Chou <mcchou@chromium.org>
Commit-Queue: Puthikorn Voravootivat <puthik@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>

[modify] https://crrev.com/632e800718e4ad0ebe09951c36d4329403539799/doc/device-api.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/a741da9ba873ec39503c7c0f96856d95f214c207

commit a741da9ba873ec39503c7c0f96856d95f214c207
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Thu Oct 20 02:03:38 2016

UPSTREAM: core: Add implementation of AdvertisingFlags

This adds 'AdvertisingFlags' property to Device interface.

Bluetooth Core Supplementary Spec v6 Chapter 1.3 defines Bluetooth
Flags as one of the data in advertise data. BlueZ also correctly
parses this data but never exposes it to upper layer.

BUG= chromium:618442 
TEST=ARC device can see Bluetooth Flag nRF Connect App

Change-Id: Ia87bd0c6cb3b349caf8e22f92883a825554523f3
Reviewed-on: https://chromium-review.googlesource.com/402213
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
Trybot-Ready: Miao-chen Chou <mcchou@chromium.org>
Commit-Queue: Puthikorn Voravootivat <puthik@chromium.org>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>

[modify] https://crrev.com/a741da9ba873ec39503c7c0f96856d95f214c207/src/device.h
[modify] https://crrev.com/a741da9ba873ec39503c7c0f96856d95f214c207/src/adapter.c
[modify] https://crrev.com/a741da9ba873ec39503c7c0f96856d95f214c207/src/device.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/bdf0ae66beea770b389c7fd7dbf2b5d40b9679ec

commit bdf0ae66beea770b389c7fd7dbf2b5d40b9679ec
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Thu Oct 20 19:52:14 2016

CHROMIUM: Make AdvertisingFlags non experimental.

This removes experimental flag from newly added
BlueZ.Device1.AdvertisingFlags property.

BUG= chromium:618442 
TEST=ARC device can see Bluetooth Flag nRF Connect App

Change-Id: I583f1b64c56e6b00ff307bec0cd05e3116503135
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/402214
Trybot-Ready: Miao-chen Chou <mcchou@chromium.org>
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>

[modify] https://crrev.com/bdf0ae66beea770b389c7fd7dbf2b5d40b9679ec/src/device.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/system_api/+/600a7341c71162586df965d56f4c88dd6f6f8c88

commit 600a7341c71162586df965d56f4c88dd6f6f8c88
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Mon Oct 24 22:26:43 2016

service_constants: Make property name for advertising flags match upstream

The new advertising data flags property in BlueZ.Device1 got a
different name when sent internal Chromium patch to upstream.
This changes the service_constants to match upstream name of
that property.

BUG= chromium:618442 
TEST=emerge system_api

Change-Id: I3a2a92e593df6b2f5cd29db9511a1cb092e77e66
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/402215
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>

[modify] https://crrev.com/600a7341c71162586df965d56f4c88dd6f6f8c88/dbus/service_constants.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0dd82b1c975662a10f34a53b3df56d98526b36d0

commit 0dd82b1c975662a10f34a53b3df56d98526b36d0
Author: puthik <puthik@chromium.org>
Date: Thu Oct 06 05:03:03 2016

bluetooth: Expose service data from BlueZ

BlueZ exposed Bluetooth device's ServiceData as a{sv} property[1]
where the dict value variant is an array of byte.

This CL exposes that to upper layer by
- Add support to map<string, vector<uint8_t>> in dbus::Property
- Add new service_data property in BluetoothDeviceClient
- Implement GetServiceDataUUIDs() and GetServiceDataForUUID()
  in BluetoothDeviceBlueZ
- Fix misc style issues in original code to make linter happy

[1] http://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/device.c#n2551

BUG= 618442 , 653310 ,b:28670943
TEST=Manually tested.

Review-Url: https://codereview.chromium.org/2369423003
Cr-Commit-Position: refs/heads/master@{#423434}

[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/dbus/property.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/dbus/property.h
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/dbus/property_unittest.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluetooth_device.h
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluez/bluetooth_adapter_bluez.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluez/bluetooth_bluez_unittest.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluez/bluetooth_device_bluez.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/bluez/bluetooth_device_bluez.h
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/dbus/bluetooth_device_client.cc
[modify] https://crrev.com/0dd82b1c975662a10f34a53b3df56d98526b36d0/device/bluetooth/dbus/bluetooth_device_client.h

[Automated comment] removing mislabelled merge-merged-2840

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/23399e4540ec7e6e17fcf03fd45248d7e947caf5

commit 23399e4540ec7e6e17fcf03fd45248d7e947caf5
Author: puthik <puthik@chromium.org>
Date: Fri Nov 04 19:38:17 2016

bluetooth: Expose missing advertise data

This CL does the following.
- Make dbus Property support unorder_map<uint16_t, vector<uint8_t>>
  for Manufacturer Data.
- Expose Manufacturer Data and  Bluetooth Flags from BlueZ device
  property in bluez::BluetoothDeviceClient.
- Add new BluetoothDevice and BluetoothDeviceBluZ API to query
  Manufacturer Data and Bluetooth Flags.

This required upstream BlueZ patch at
http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=f96e4a9f
http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=9caa0457
And the system_api patch at http://crosreview.com/398418

BUG= 618442 
TEST=nRF Connect App in minnie can see all advertise data

Review-Url: https://codereview.chromium.org/2421713002
Cr-Commit-Position: refs/heads/master@{#429980}

[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/dbus/property.cc
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/dbus/property.h
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/dbus/property_unittest.cc
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/bluetooth_adapter.h
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/bluetooth_device.cc
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/bluetooth_device.h
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/bluez/bluetooth_adapter_bluez.cc
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/bluez/bluetooth_bluez_unittest.cc
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/bluez/bluetooth_device_bluez.cc
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/bluez/bluetooth_device_bluez.h
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/dbus/bluetooth_device_client.cc
[modify] https://crrev.com/23399e4540ec7e6e17fcf03fd45248d7e947caf5/device/bluetooth/dbus/bluetooth_device_client.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d922bbb7db1751071dc8fcfb819de56a76aeaf27

commit d922bbb7db1751071dc8fcfb819de56a76aeaf27
Author: puthik <puthik@chromium.org>
Date: Fri Nov 04 20:34:52 2016

arc: bluetooth: Send missing advertise data to Android

This CL sends Manufacturer Data, Advertising Data Flags and
Tx power level to Android when discovering for new devices.

BUG=646584,  618442 
TEST=nRF Connect App in minnie can see all advertise data

Review-Url: https://codereview.chromium.org/2425813003
Cr-Commit-Position: refs/heads/master@{#430001}

[modify] https://crrev.com/d922bbb7db1751071dc8fcfb819de56a76aeaf27/components/arc/bluetooth/arc_bluetooth_bridge.cc

Everything is in now. Since this is require switching BlueZ 5.41 branch which targets to M56. I update this bug to also target M56.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/1a63536db7e0554fc44cb0bcc7057c607320c3ca

commit 1a63536db7e0554fc44cb0bcc7057c607320c3ca
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Wed Apr 19 07:15:42 2017

CHROMIUM: Make AdvertisingFlags non experimental.

This removes experimental flag from newly added
BlueZ.Device1.AdvertisingFlags property.

BUG= chromium:618442 
TEST=ARC device can see Bluetooth Flag nRF Connect App

Old-Change-Id: I583f1b64c56e6b00ff307bec0cd05e3116503135
Change-Id: I64ef611ea493738d4e6b2a0c3c0fa3a177075f8b
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/469431
Reviewed-by: Rahul Chaturvedi <rkc@chromium.org>
Tested-by: Miao-chen Chou <mcchou@chromium.org>
Commit-Queue: Miao-chen Chou <mcchou@chromium.org>
Trybot-Ready: Miao-chen Chou <mcchou@chromium.org>

[modify] https://crrev.com/1a63536db7e0554fc44cb0bcc7057c607320c3ca/src/device.c