It uses your movement and location to determine what noise-cancelling mode to put the headphones in. It is awful at picking though, not worth the privacy implications or battery life drain.
Which, IIRC, is because having BLE access equates to having location permissions, in the sense that you can reconstruct someone’s location from the BLE tags (Bluetooth MAC addresses) you sense, using location correlates of those tags in a separate database you’ve purchased. (This is equivalent to how phones reconstruct their location—in absence of GPS signal—using a wi-fi SSID triangulation database.)
Due to the bad layering of the BLE model it’s next to impossible to actually hide from the app the data of what peers are around the device, while still allowing the app to communicate over BLE. This isn’t true of regular Bluetooth, but BLE is solving a harder problem, sort of like how WebRTC is solving a harder problem than HTTP.
Still, you’d hope they’d come up with some way to obscure the peer BT MAC addresses or something. Maybe an approach like Apple used with device IDs, where each app sees the device ID hashed with a per-app salt—each app would see a separate list of virtual BT MACs that, when it sent messages to, the OS would translate back to the real MACs. Like BT “file handles”, almost.
