Bluetooth feature request: ability to different BLE public vs. random addresses

[XenoKovah]

I may just be missing it, but AFAICT currently the raw WiGLE data (as obtained by looking at the SQLite schema) only encodes whether a Bluetooth address is Classic/BR/EDR ("B") or BLE ("E"). However, BLE has both "public" addresses (which behave the same as classic, and the top 24 bits are an OUI), and "random" addresses (which have 3 sub-types, "random static", "random private resolvable", and "random private non-resolvable", which are differentiated based on their 2 MSBits).

The request is to introduce a new mnemonic (e.g. "R" or something like that if that's already used), to make it clear which BDADDRs are BLE random type (and then anyone wanting to know which specific type can just check the top 2 bits themselves. Or perhaps this could go in the capabilities field?)

[rksh]

To date, we haven't discovered a way to get the Txadd/Rxadd bits from the PDU header via the Android LE ScanRecord. If my reading of the spec is right, we need these in addition to the address to conclusively determine public/random - is this correct?

https://stackoverflow.com/questions/23471364/private-vs-public-addresses-in-bluetooth-low-energy-on-android discusses the issue in detail, but the only "solution" is checking for matches against the known OUI list (which would be inefficient considering the density of BLE signals in our world) or speculative things that ignore Android's BLE architecture.

We're open to suggestions and pull requests, with the caveat that it needs to be fast enough to populate the dynamic display elements and avoid slowing scanning unduly.

I'd prepped a provisional branch with display icons (dice, balaclavas) for random / private and a DB schema extension, but without a reliable/fast indicator, we're stuck.

[XenoKovah]

To date, we haven't discovered a way to get the Txadd/Rxadd bits from the PDU header via the Android LE ScanRecord. If my reading of the spec is right, we need these in addition to the address to conclusively determine public/random - is this correct?

Yes, effectively.

deleted red herring

It looks to me like you have access to BluetoothDevice objects here: https://github.com/wiglenet/wigle-wifi-wardriving/blob/1d29b294071bfd96a3419dd239a1fe7025a08e55/wiglewifiwardriving/src/main/java/net/wigle/wigleandroid/listener/BluetoothReceiver.java#L185C5-L185C71

It looks like those have ADDRESS_TYPE_RANDOM which has the right kind of description for the 3 subtypes (and ADDRESS_TYPE_PUBLIC as well.)

[rksh]

I'll check these out - they're only included in SDK 33 and up, so not even available on the vast majority of the current installed base.

[XenoKovah]

Yeah in the previous thing I deleted (but may have been in an email), it was SDK 33 and up, but the more-likely-correct one in BluetoothDevice looks like it's a little better as it's SDK 31 and up. It's a little crazy to me if there was no way to do this before that, but I agree that to a first look that does seem to be the case for Android.

[rksh]

ah wonderful - https://developer.android.com/reference/android/bluetooth/BluetoothDevice#getAddressType() the method to get the address type was finally added in SDK 35 (Android 15, which came out this summer.) The footprint will be "only recent devices," but we'll at least know public v. random.

It will require some testing - perhaps we can read it from the Parcelable output in previous versions