Here is an example of garbage trailing data reported by the scanner:

Problem # 2:  Advertisements are received with bad data
The following are examples of advertisements received from two devices
02 01 06 14 09 4E 6F 6E 69 6E 33 32 33 30 5F 35 30 31 39 30 30 30 38 33 11 07 1B C5 D5 A5 02 00 5E 8B E2 11 5F 0D E0 70 A9 46 0B 03 0F 18 22 18 05 18 0A 18 00 18 [end of real data] 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 68 00 00 00 06 00 00 00 10 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 10 00 00 00 01 00 00 00 68 00 00 00 00 00 00
14 09 4E 6F 6E 69 6E 33 32 33 30 5F 35 30 31 39 30 30 30 38 32 11 07 1B C5 D5 A5 02 00 5E 8B E2 11 5F 0D E0 70 A9 46 0B 03 0F 18 22 18 05 18 0A 18 00 18 00 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 68 00 00 00 06 00 00 00 10 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 10 00 00 00 01 00 00 00 68 00 00 00 00 00 00
The actual data sent by the devices is shown. The attachment of the garbage data at the end of the real data can cause serious problems for the decoder. There is nothing in the advertisement passed to the decoder that tells the decoder how long the entire advertisement is. An advertisement is parsed by given first a length field of a data segment followed by a code of what the data segment is. At the end of that segment is the length field of the next segment. That could be garbage data but both the length field and the following value could be by chance an actual data segment type whose values are, unfortunately, garbage, but result in values that appear to be valid. 
In the two examples above, the first piece of garbage data is 0 which says the length field is zero. Since this value is not possible, the LNI decoding algorithm quits and nothing bad happens. That would not be the case if the next two bytes happened to be 02 03 which indicates that the next two bytes are a 16-bit service UUID.

Tried testing the issue on chrome reported version# 69.0.3497.81 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and tried installing BLE Scanner
2) It is asking to "Install on my devices"

@Reporter: Please find the attached screenshot for your reference and let us know if we missed anything in reproducing the issue, could you please confirm if this issue requires Mobile device to test, provide your inputs on it which help in further triaging the issue in better way.

Thanks!

Deleted: 880538.PNG 83.1 KB

	880538.PNG 83.1 KB View Download

I am not sure what is being attempted here. To duplicate the bug one needs to install a BTLE scanner that runs on the Android platform. It looks like this app is from Microsoft which I suspect would be for Windows.

The bug reported was found when installing an Android gateway application that runs on Android devices. The application used was LniPlugfestPHG and it is available on the Google Playstore. Search for LniPlugfestPHG. This Apk needs to be installed on the Android running on the Chrome book. I have no idea how the Android platform is integrated into Chromebook but I have made the assumption it shall behave like any of my standalone Android devices.

The LniPlugfestPHG on the Playstore does not have some workarounds I have implemented for the Chromebook (mainly encryption checks) but that should only cause problems when reconnecting to a BTLE device.

All you need to do is run the application and look at the Logcat output. Of course you will need a BTLE health device supported by the app. You should get the same logcat output as I have shown above. What has been printed to the log is raw bytes reported by the scanner in the callback.

Hope this helps.

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

Based on comment #5, changing the OS from Windows to Chrome OS.  

qiyuh, is this the same as the advertisement issues you've been working to solve in ARC++? Can you take a look at this issue? Thanks!

 Issue 887029  has been merged into this issue.

As reproduced in  issue 887029 , this is still present in 71.0.3578.27

As reproduced in   issue 887029  , this is still present in 71.0.3578.49

Too late to merge to 71 for now. Have to wait until 72.

This is still present in 72.0.3609.3