Hi Gio, this report showed that bluez had sent the device advertisement report to bluetoothctl, cras, and thus theoretically chrome browser, but the device was not showing up in the device list in settings page. Note that this headset advertises using LE. 

The system logs in hychao@'s feedback report was attached.

Would you please take a look or re-assign if proper? Thanks!

Deleted: 85753038079-system_logs.zip 1.6 MB

85753038079-system_logs.zip 1.6 MB Download

Could you unpair the device and then go to chrome://bluetooth-internals/#devices, start a scan, and send a screenshot of the devices there? I'm trying to figure out if the device is being filtered out by the UI.

Here's another feedback about finding BT headset in pair list
https://listnr.corp.google.com/product/5015361/report/85723200933

update to the original issue:
 - attachment is the device list of chrome://bluetooth-internals, in html format. I do see my headset 'Beoplay H5' in scanning result.
 - After a long waiting, probably 5-10 minutes, I finally see 'Beoplay H5' show up in 'unpaired devices' section of UI.

Deleted: nocturne-bt-internals.html 37.0 KB

nocturne-bt-internals.html 37.0 KB View Download

Thanks for that. It seems that there is a bug in our filtering code, rather than in our API code.

One last request: would you mind downloading "nrf Connect" on an Android device or on your Chromebook, looking for your device and then sending a screenshot of its information. See the attached screenshot for an example.

Deleted: screenshot.png 204 KB

	screenshot.png 204 KB View Download

Yup, just as suspected. If a device advertises as LE only, we will filter it out if it doesn't have a HID UUID.

rkc, omrilio: this is an example of our BT filtering being too strict. We could whitelist the Service UUID which corresponds to the manufacturer, but there is a high chance this will happen again for another manufacturer.

My proposal would be to just match Android and filter out devices without a name. Which is what we currently do for Classic and Dual devices.

I think we should target merge the fix to M71

I agree. We just need to agree on the fix :)

Hi Gio, just would like to make sure that I understand it correctly. Hsin-yu said that the headphone eventually (after about 5 mins) showed up in the UI. If the headphone did not have a HID UUID, why did it show up eventually?

An issue with whitelisting manufacture UUID is that if all devices from the whitelisted manufacture would show up in the UI. This might not be a big issue for now though.

Yeah, that is strange. It's possible that after some time the advertisement packet changes and we no longer filter it out. But based on the advertisement in #5 we are filtering it out.

Given this blocks functionality, I am fine with loosening the filtering.
Omri, IIRC you requested this feature in the first place - are you fine with that too?

The filtering should not filter headsets, to my understanding it should only filter Gatt BLE devices per issue 808713 which would only affect devices that require an app and should never be visible.

Is that not the case? Where does this device fall under? 

where is the code located? I can help print some log to debug.

Sadly, there is no reliable way to distinguish between BLE devices that require an app and some BLE headsets.

We were assuming that LE headsets would advertise a Service UUID or would be dual mode devices. But these Beoplay H5 headphones prove this is not always the case. These headphones don't advertise any Service UUIDs that indicate they are headphones nor do they advertise themselves as dual devices.

One thing I want to point out is that while UI not showing this headset during scan, ChromeOS audio server does recognize this headset and identifies its capability to profiles: A2DP/HFP/HSP/AVRCP
I enabled debug log to CRAS and got below lines to this BLE headset:

localhost ~ # grep '78:36' /var/log/messages
2018-11-06T11:15:57.693759+08:00 INFO cras_server[12804]: Bluetooth Device: 00:09:A7:23:78:36 added
2018-11-06T11:18:42.357175+08:00 DEBUG cras_server[12804]: Bluetooth Device: 00:09:A7:23:78:36 is A2DP sink
2018-11-06T11:18:42.357193+08:00 DEBUG cras_server[12804]: Bluetooth Device: 00:09:A7:23:78:36 is AVRCP remote
2018-11-06T11:18:42.357203+08:00 DEBUG cras_server[12804]: Bluetooth Device: 00:09:A7:23:78:36 is HFP handsfree
2018-11-06T11:18:42.357212+08:00 DEBUG cras_server[12804]: Bluetooth Device: 00:09:A7:23:78:36 is HSP headset

These lines are logged by:
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/cras_bt_device.c#739

In CRAS we're using the device API from blueZ
https://chromium.googlesource.com/chromiumos/third_party/bluez/+/master/doc/device-api.txt#134

and in the 'PropertiesChanged' dbus signal, look for the property 'UUIDs' and compare against audio related constants, per
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/cras_bt_constants.h

I am no expert in BT advertisement. Base on the discussion and logs I got, it looks like ChromeOS UI uses different BlueZ API than CRAS.
Is this something can be fixed by making Chrome OS UI adopt the correct API?

Talked with Omri offline; he's OK with just filtering based on name.

hychao: Thank you for the offer. The problem is not the API, it's that we filter out some devices based on the advertisement packet. That happens here[1]. From the screenshot you sent earlier we know the device is a LE-only devices and it has no UUIDs in its advertisement so it will get filtered out.

[1] https://cs.chromium.org/chromium/src/device/bluetooth/chromeos/bluetooth_utils.cc?l=63-70

If we want to reduce the number of devices in the list we could also filter out devices that have low RSSI which often means that the device is far away.

Holding off on this because there are concerns that this forces us to connect in a way that is not specified in the Bluetooth Spec. The manufacturer is aware that this causes problems and has a workaround[1].

[1] https://bogo.custhelp.com/app/answers/answer_view/a_id/1036554

The link from #19 mentions two "BLE" and "Classic" button to select while pairing on a Samsung phone, which is not the case we have in Chrome OS UI.

Can you provide more detail about what does it mean by: "forces us to connect in a way that is not specified in the Bluetooth Spec"?

As a user when I first seeing this problem, I would blame this bad experience to ChromeOS, instead of to headset manufacturer. Simply because Android phone works well with this headset.

Note that there's internal feedback complaining this, on another Beoplay headset("Beoplay E8", mine is "H5")
https://b.corp.google.com/issues/117746727

Hsin-yu discussed this issue further with me offline. In C#15, the Beoplay headphone was not paired/connected, but its audio related profiles were actually received. It was weird that the Beoplay device did not show up in the UI settings page.

Hence, we decided to do more experiments and captured logs. To sum up, even when Beoplay was discovered with its BR/EDR address, it did not show up in the UI settings page. The issue was not caused by filtering since Beoplay was discovered as a classic device.

In the attached logs, the experiment was conducted from 2018-11-07 16:48:43 to 2018-11-07 16:50:54.

The device was discovered as a BR/EDR device between 16:49:22 and 16:50:39 in the btsnoop log. But in the attached screen shot taken at 16:49:53.482952, it did not show up in the UI.

A typical EIR looks like

@ MGMT Event: Device Found          2018-11-07 16:49:22.687042
  BR/EDR Address: 00:09:A7:23:78:36 (Bang & Olufsen A/S)
  16-bit Service UUIDs (partial): 7 entries
      Advanced Audio Distribution (0x110d)
      Audio Sink (0x110b)
      A/V Remote Control (0x110e)
      A/V Remote Control Controller (0x110f)
      Handsfree (0x111e)
      Headset (0x1108)
      Headset HS (0x1131)
  Name (complete): Beoplay H5
  Class: 0x240418
      Major class: Audio/Video (headset, speaker, stereo, video, vcr)
      Minor class: Headphones
      Rendering (Printing, Speaker)
      Audio (Speaker, Microphone, Headset)

I conducted such experiments 4 times. In the first time, the Beoplay headphone showed up in the UI in 5 seconds. For the 2nd, 3rd, and 4th time, the headphone failed to show up in a couple of minutes. I think the headphone somehow got lost and did not show up in UI. And this is not a filtering issue since the headphone was actually discovered as a classic device.

Deleted: 1107_1648_none_Beoplay.tbz2 7.9 MB

1107_1648_none_Beoplay.tbz2 7.9 MB Download

Deleted: Screenshot 2018-11-07 at 4.49.53 PM.png 445 KB

	Screenshot 2018-11-07 at 4.49.53 PM.png 445 KB View Download

Ok. I ordered the headphones and will investigate once I get them.

I figured out what is going on. It seems BlueZ doesn't emit a property changed signal when the type changes[1][2]. So if Chrome finds the device while it's advertising as LE, it will never notice it started using Classic. The fix should be for BlueZ to emit a property changed signal when the type changes. sonnysasaka, qiyuh: could you make this change?

I don't know how hard it is to merge BlueZ patches to branches. If absolutely necessary we could temporarily poll from the Chrome side to update the type property.

[1] https://cs.corp.google.com/chromeos_public/src/third_party/bluez/src/device.c?g=0&l=4403
[2] https://cs.corp.google.com/chromeos_public/src/third_party/bluez/src/device.c?g=0&l=4412

Thanks for figuring out this! It's not harder to merge BlueZ to branch. So it's better to fix in in BlueZ rather than having the poll hack in Chrome. I will send a patch soon.

Thanks Gio for figuring this out and Sonny for writing up quickly a patch to fix that!

I still have a question about how chrome regards such a dual-mode device. In C#21, the headphone sends out a EIR report including audio profiles and its audio class. And then bluez would accordingly send out an "EIR" property changed signal to chrome. Has Chrome received this information? I guess this "EIR" property indicates the headphone is a classic BREDR device as well as its audio class which looks enough for chrome to make a correct decision about filtering. 

https://cs.corp.google.com/chromeos_public/src/third_party/bluez/src/device.c?type=cs&q=package:%5Echromeos_public$+device_set_eir&g=0&l=1686

The EIR property was recently introduced and we don't use it for filtering. IIUC, BlueZ parses the EIR and then sends signals for the properties that changed e.g. UUIDs, class, name, etc. which we use when filtering.

(I was under the impression that the EIR property only applied to classic devices. Qiyu, is that not the case?)

Re Comment #25: Joseph, Chrome doesn't deduce the type based on EIR, but rather directly consume the "Type" property emitted by BlueZ[1]. So even though BlueZ has been correctly notifying clients for EIR changes, it has not been affecting Chrome on deciding the Type, which in turn is needed to determine whether to filter the device in the UI.

[1] https://cs.chromium.org/chromium/src/device/bluetooth/bluez/bluetooth_device_bluez.cc?l=222

Re C#26: AFAIK, EIR is only provided by classic devices. On the other hand, "scan response" is the corresponding part in LE devices.

Re C#27: thanks for the explanation! 

Hi Gio, with Sonny's patch, could you please test if that solves the issue? Thanks!

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

commit 7efd4faf52d7da7cbca5dd4a65e635d2eeb234eb
Author: Sonny Sasaka <sonnysasaka@chromium.org>
Date: Fri Nov 16 13:02:11 2018

CHROMIUM: Always send D-Bus signal when device LE/BREDR type changes

Some devices get recognized as Classic a lot later than LE. This makes
client unable to detect the change when it finally is detected to have
Classic support. Adding PropertyChanged signal makes sure clients are
notified when this changes.

BUG= chromium:900112 
TEST=Tested manually with BlueZ on linux against Beoplay H5

Change-Id: Iac118d072663d15f88ec9966c6dd33a5b151d48a
Reviewed-on: https://chromium-review.googlesource.com/1337770
Commit-Ready: Sonny Sasaka <sonnysasaka@chromium.org>
Tested-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Qiyu Hu <qiyuh@google.com>

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

Tested on Canary and the fix works. Requesting merge to 71 since this affects quite a few high-end headphones.

This bug requires manual review: We are only 5 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi, we're fairly late into M71. Is this a M71 regression?  Is #29 the only CL under consideration for the merge?  Risk?

Sorry about that. Yes, this is a regression. We introduced a filter for Bluetooth devices and it filters out some high end headsets. Yes The CL in #29 is the only one we need to merge. It's a simple 4 line change so the risk is pretty low.

By 'filters out some high end headsets' I assume that means they wouldn't be usable at all?

Yes, they wouldn't even appear on the list of Bluetooth devices to connect to.

Approving merge to M71 Chrome OS.

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

commit f8306c7f6545ce7c03ce8f61d1a91c7f015f46a5
Author: Sonny Sasaka <sonnysasaka@chromium.org>
Date: Fri Nov 30 19:35:42 2018

CHROMIUM: Always send D-Bus signal when device LE/BREDR type changes

Some devices get recognized as Classic a lot later than LE. This makes
client unable to detect the change when it finally is detected to have
Classic support. Adding PropertyChanged signal makes sure clients are
notified when this changes.

BUG= chromium:900112 
TEST=Tested manually with BlueZ on linux against Beoplay H5

Change-Id: Iac118d072663d15f88ec9966c6dd33a5b151d48a
Reviewed-on: https://chromium-review.googlesource.com/1337770
Commit-Ready: Sonny Sasaka <sonnysasaka@chromium.org>
Tested-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Qiyu Hu <qiyuh@google.com>
(cherry picked from commit 7efd4faf52d7da7cbca5dd4a65e635d2eeb234eb)
Reviewed-on: https://chromium-review.googlesource.com/c/1357320
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
Commit-Queue: Sonny Sasaka <sonnysasaka@chromium.org>

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

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot