fwiw, we discussed this issue with puthik when he was working on Arc++. This caching policy applies to many attributes in advertisements e.g. UUIDs, name, etc. and BlueZ is the only API that does this. We figured the best solution was to follow all other APIs[1][2][3] more closely and introduce a ScanResult property which is changed for each advertisement. This property would contain the RSSI and the raw bytes of the advertisement. This would avoid having to send a new Property Changed signal for all the properties that BlueZ caches but also allow us to control how we want to expose each advertisement. On the downside we would have to parse the data but at least we can be sure it will be thoroughly tested and we can even fuzz it. Ideally this could be done upstream since we need to support Linux as well.

[1] https://developer.android.com/reference/android/bluetooth/le/ScanCallback.html#onScanResult(int, android.bluetooth.le.ScanResult)
[2] https://developer.apple.com/reference/corebluetooth/cbcentralmanagerdelegate/1518937-centralmanager?language=objc
[3] https://docs.microsoft.com/en-us/uwp/api/windows.devices.bluetooth.advertisement.bluetoothleadvertisementwatcher

Assigning to myself so it doesn't get lost in the churn.

We could perhaps stop caching advertisement data for non-connectable but these devices are not supposed to be persisted once the scan is stopped so I don't know if this is really a problem or you are talking about connectable devices, in that case the advertisement data can be related to GATT services or other profiles that may use the advertisement data as a discovery procedure.

Re #5, stop caching for non-connectable devices would be an improvement but is not enough for us. Both Arc++ (i.e. Android) and Web Bluetooth Scanning require us to provide per scan result info for all devices, connectable and non-connectable.

For example, imagine a beacon that is alternating between two different advertisement packets: one with Service Data for 0xFF00 and one with Service Data for 0xFF01. Android (and thus Arc++) require us to dispatch a OnScanResult[1] event for each of these advertisement packets with information only about that adv. packet i.e. if the last received packet has Service Data for 0xFF00 we should dispatch the event only with that data.

[1] https://developer.android.com/reference/android/bluetooth/le/ScanCallback.html#onScanResult(int, android.bluetooth.le.ScanResult)

My understanding is that these APIs are to do things that are not really meant to be done with advertisements for 2 important reasons:

1. It is unreliable because there is no guarantee that no Advertisement will be missed as we can't do full duty cycle scanning.

2. There will be a much better solution that is:  https://www.bluetooth.com/search-results?q=mesh&fq= (actually this one might kill raw advertisement APIs completely since they would compete for advertisement time)

I don't think 1. is that big of a problem. No API, including Android's makes that guarantee. 

Even if 2. is a better solution we still need to support Android's APIs.

From vudentz:

there is now an option to see each advertisment data, just use ResetData filter, though the kernel will still set the duplicated filtering but bluetoothd won't prevent duplicated service and manufacturer data like it is currently.

James now owns connectivity in Chrome OS UI, over to him.