Confirmed that this is an introduced bug. The older version 68.0.324440.118 does not have this issue.

Thanks for filing the issue!

From comment#0, it is understood that the issue seems to be triaged using an Android device hence adding appropriate labels for further triaging.

@ brianbreinhold: Installed attached app from  crbug.com/885339 , Observed Connected BLE feature : Yes and device: Bluetooth is enabled. Could you please let us know how to proceed further? If this is not sample app please provide test apk along with screencast. This would help in further triaging of the issue.

Also cc'ing  qiyuh@ from bugs  880530  and  885339  for further inputs on this issue.

Thanks!

You will need a compatible pairable health device. I just took a sniff with a Nonin BTLE Pulseoximeter. It connects and pairs and delivers measurements on a first-time connect. However, after it disconnects and a second measurement is taken, it advertises as usual as can be seen on the sniff. But the Chromebook BluetoothLeScanner never signals the ScanCallback of these advertisements. On the other hand, if I make another BTLE advertise, it WILL signal the ScanCallback. For some reason, the paired device is getting filtered out. Note that the BluetoothLeScanner uses the ScanFilter to filter on UUIDs.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Heard from the partner that they are confident that this issue can be reproduced with any touchscreen Chromebook. They are using an HP Chromebook x360 11 G1 EE. (http://www8.hp.com/us/en/products/laptops/product-detail.html?oid=15747870).  I have inquired with the partner regarding the bluetooth devices that they seem to be having issues to see if we are able to receive loaner devices for testing.

Is this still an issue on the latest stable channel?

I spoke with the bug submitter and they indicated that this is still reproducible in the stable channel.

Please let me know if you need any more details.

What's the chromeos version on the stable channel last time the bug submitter tested this one?

"Chrome version: 72.0.3609.3  Channel: stable" in the description looks a bit surprising as 72 won't come until February.

Reached out to the bug submitter for an update.

I tested on R71-11151.100.0 and failed to reproduce this bug.

You are correct in verifying, reporter only tested on M72 and not M71.  Reporter mentioned that the issue is still occurring under M72.

Sorry for the confusion.

Could we ask the reporter to take a look at M71? Thanks.

Yes, I requested this.  Waiting to hear back from the reporter.

I do not know how to install updates or where to get them

https://support.google.com/chromebook/answer/1086915?hl=en

You should also be able to find your chromeos version under "About ChromeOS". Please include that with your testing results. Thank you!

This guide should help:

https://support.google.com/chromebook/answer/1086915?hl=en

my version is 72.0.3609.3

dev channel

This maybe the only way I can install my applications.

iT LOOKS LIKE MY APP MAYBE deleted if I do this. If that is so I won't be able to test. We had to go through lots of hoops to be able to install applications from Android Studio.

I would like to add that there is a step missing after the 'powerwash' button. Nothing happens until you go back to the top and select show details. THEN the upload of the new data starts.

After restarting a couple of times and getting back into developer mode my app was visible once again.

The bug still exists. 71.0.3578.94 stable channel

The startDiscovery() method does signal the ACTION_FOUND in a BroadcastReceiver, but the BluetoothLeScanner is still not getting signaled anything. The app does not respond to BLE events from calling the startDiscovery() method because there is no data provided about disocvered BTLE devices. It is only used for SPP and HDP devices. The BluetoothLeScanner is used to handle BTLE devices as advertisement data is available. Google messed up big time with handling BTLE devices in their startDiscovery() method as to render it essentially useless. In any case, build 71 is experiencing the same problem as the dev channel build 72.

I am not able to reproduce this bug, still. Steps I tried:

1. Install the nRF connect app https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp&hl=en_US
2. Start advertisement on another bluetooth device (cellphone in my case)
3. Pair with that device
4. Change the advertisement data, say service uuid from that device
5. Observe change of advertisement data on my chromebook (DUT)

You mentioned that "but the BluetoothLeScanner is still not getting signaled anything". Let's forget, for a moment, the startDiscovery() API and focus on BluetoothLeScanner. By "still not getting signaled anything", do you mean that you start scanning on BluetoothLeScanner and nothing happens after that?

To be more specific, what's the result of the following experiment on your side?
1. Start scanning on BluetoothLeScanner
2. Start advertisement on another UNPAIRED bluetooth device
3. Pair with that device on your chromebook (DUT)
4. Change the advertisement data on the now paired bluetooth device
5. Observe the change of advertisement data on your DUT

Thank you and please, again, include your chromeos version with the result, which will hugely help me triage.

P.S. You can easily change the advertisement data with the nRfConnect app above on your cellphone.

Just to add some more details.  We did drop off a device the other day as the issues seem to be BLE device specific.  Did you happen to have that additional device?  If not we can sync offline to get that over to you.

You will need a app that uses the Android BluetoothLeScanner to search for BTLE devices. Use

https://play.google.com/store/apps/details?id=com.lampreynetworks.ahd.oilbath2

This application is health-device specific. When it starts it uses the BluetoothLeScanner to search for BTLE devices for 10 seconds turns off and then does a startDiscovery() for 5 seconds and repeats. The startDiscovery() method is an old method that pre-dates BTLE and Android added scanning to the operation but it does not expose any information about a BTLE device when one is discovered. So the app skips discovered BTLE devices from a discovery. However the BluetoothLeScanner.startScan() passes up the advertisements when it discovers a device so the app looks for BTLE devices during this phase. It also prints the ads to logcat when it discovers one it understands.

Note the app FILTERs on UUIDs, so any device NOT a health device the app cannot handle is ignored.

So before running the app, clear all paired devices (if any).
Start the app.
Make a Health device pairable (the Omron BP for example)
It will popup on the screen.
say yes
it will pair. Accept pairing if you get any dialogs
When it disconnects, take a measurement with the cuff
It will not reconnect
If you look at logcat you will see no advertisements being discovered by the scanner.
If you unpair and take another measurement you will see advertisements in log cat

So before running the app, clear all paired devices (if any).
Start the app.
Make a Health device pairable (the Omron BP for example)
It will popup on the screen.
say yes
it will pair. Accept pairing if you get any dialogs
// The device doesn't pair and not dialog pops up

If I understand correctly, this device is doing LE advertisement but requires bluetooth classic connection, which generally is not the standard practice of bluetooth.

Does this device support LE connection?

Another question is whether this device works on iOS? As far as I know, among major operating systems, only Android tries both LE and Classic connection to a bluetooth LE device. We do not recommend that we depend this Android-specific behavior as Android could also move on to a more standard one in the future.

This device supports an LE connection and ONLY an LE connection. It does not support classic. Android in its wisdom does BOTH a BTLE scan and a classic discovery ping at the same time when the application calls BluetoothAdapter.getDefaultAdapter().startDiscovery(). However, if you see in your BroadcastReceiver a device found event and it is BTLE, you need to invoke BluetoothDevice.connectGatt() to invoke a BTLE connection.

If a device advertises (even it its BTLE advertisment) that it supports both BTLE and classic, Android will connect classic UNLESS you invoke the extra parameter in the connectGatt() to actually connect GATT. However, the devices we have listed only support BTLE and that is not a problem. Our software uses the extra parameter to assure a Gatt connection for all BTLE devices in any case.

All the devices we have mentioned work as expected with the LniPlugfestPHG2 on all 'true' Android platforms we have used. There are too many to have tried them all of course.

This device works on iOS. All the BTLE standard health devices that are familiar with work on iOS.

I should add that our app does not connect to BTLE when it discovers a BTLE through the startDiscovery() call. We use that method only to discover and connect to SPP and HDP classic health devices.

For BTLE devices we use the BluetoothLeScanner (both the old and new versions depending upon the Android OS version). The BluetoothLeScanner ONLY does BTLE scans and detects only BTLE advertisements. Recall classic discovery requires that the manager SEND packets whereas BTLE discovery involves the manager LISTENING for advertisement packets. They are opposite!

I would also like to restate that the Chromebook DOES detect BTLE advertisments when paired BUT ONLY through the startDiscovery() call. The problem is with the BluetoothLEScanner class. For some reason, the advertisements are not passed to the BLuetoothLeScanner callbacks when the device is paired.

One would then think, why not use the startDiscovery()? The answer is because the startDiscovery ONLY gives you a BluetoothDevice object which has  no information about BTLE devices. The only thing you know is that it supports BTLE. So you don't know if the BTLE device is a mouse, headphones, or a health device. The BluetoothLeScanner callback, on the other hand, gives you the advertisements and that can give you all kinds of info about the device, most important being the supported services....like 'Thermometer service'.

Could I ask how you get the omron device paired in the first place? ChromeOS doesn't provide a UI for users to type in the passkey. We probably need to resolve crbug/911651 first.

Hmm, I was able to enter passkeys ... sometimes.

To pair with the Omron is a pain.

Pull the batteries
press the start button several times
reinsert
turn over and look at the screen. You should see something that indicates it is in pairing mode... a flashing 'o' on mine.

911651 does not block all passkey entries. One has to try on a device by device basis. I think that block comes up on the standard Android equivalent of asking for user confirmation. I dont have a chome book here so I can't test.

I never got my device paired. My device model is omron HEM-9200T.

We just confirmed the code that we don't have UI popup for passkey entry when the remote device request to pair with chromebook.

The connection between chromebook and omron goes as follows:
1. Chromebook tries to connect through GATT.
2. Omron sends out MITM pairing request.
3. We don't have UI popped up here on chromebook, and by default, chromebook will cancel the connection.

Which model of omron allows you to reliably (maybe I overstate this) enter the passcode?

I have the same model. The bug I had was there was a popup (not a passkey) but I could do nothing but cancel. I had a non stable version when I submitted the bugs. I have reverted to the stable channel. That may change things.

We need to loop in the UI team to see whether it's doable for use to show a dialog to manually enter a passkey when a pair request comes. There are two concerns here:

1. Not every ChromeOS device has keyboard capabilities, say a chromebox, entering a passkey makes no sense here.
2. We initially reject such pairing requests for spamming reasons, since any remote devices can initiate the request.

@jlklein, can we discuss this issue with +jhawkins also?

Yep, Qiyu, feel free to schedule some time to chat here. We might also want to loop in our PM, jessejames@.