[BLE] When can a BluetoothLE operation prompt for consent?

Gene Pavlovsky 21 Reputation points
2021-01-20T00:46:26.457+00:00

I developed a command-line program that connects to a BLE device (a motion sensor), subscribes to motion notifications, then prints the coordinates to stdout around 60 times per second. The data is consumed by a legacy Adobe AIR desktop application (which handles running of my "driver" program).

I have used Microsoft's Bluetooth Low Energy code samples as a reference.
I've found the following in one of the code samples: 

   // BT_Code: BluetoothLEDevice.FromIdAsync must be called from a UI thread because it may prompt for consent.  
   bluetoothLeDevice = co_await BluetoothLEDevice::FromIdAsync(SampleState::SelectedBleDeviceId);

Those samples are UWP apps, but my program is C++/WinRT console program, and naturally has no UI thread. So I am guessing that in case of consent prompt it will just fail.

I've finished writing the program and it's working, but this comment got me worried about some situation where this consent prompt topic will become an issue. Or perhaps it can work now, and break with some future Windows update if they introduce more widespread consent dialogs.

So far I found that pairing a device requires consent (link). My device doesn't require pairing.

I would like to know if there's a well-defined list of cases when a Bluetooth LE consent prompt might be required?

Universal Windows Platform (UWP)
C++
C++
A high-level, general-purpose programming language, created as an extension of the C programming language, that has object-oriented, generic, and functional features in addition to facilities for low-level memory manipulation.
3,709 questions
0 comments
Accepted answer
  1. Yan Gu - MSFT 2,676 Reputation points
    2021-01-20T08:47:36.007+00:00

    Hello,

    Welcome to Microsoft Q&A.

    You could control that whether the prompt for consent exists in the code.

    Referring to the linked document and the Scenario9_CustomPairDevice in the official sample, you could use DevicePairingKinds to control the pairing process. Therefore, no worry about the cases need prompt for consent, you could control it.

    And, the custom pairing is always a system-level operation, a system dialog(if needed) will always be shown to the user without the need to create your own dialog. So, no worry about that the console project without the UI thread.

    If the response is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Gene Pavlovsky 21 Reputation points
    2021-01-20T13:16:30.317+00:00

    Hello YanGu,

    Thank you for your reply!

    It sounds promising so far. I'm not sure it exactly applies in my case, because the device I'm working with doesn't require pairing. So I'm not using the PairAsync method (or DevicePairingKinds) which is mentioned in the Custom Pairing section.

    The basic flow I have is similar is based on Scenario1_Discovery and Scenario2_Client from the official BluetoothLE samples.

    Summary of what my code does:

    • Use DeviceWatcher to watch for BluetoothLE devices, add a handler for the Added event
    • In the event handler, identify my device by it's Name, and get it's Id
    • Using this Id, connect to the device using BluetoothLEDevice::FromIdAsync (here the official sample has a comment "must be called from a UI thread because it may prompt for consent")
    • Get a list of GATT services using bluetoothLeDevice.GetGattServicesAsync
    • Iterate over the list and identify the desired service by it's Uuid
    • Get a list of child characteristics of the service using service.GetCharacteristicsAsync
    • Iterate over the list and identify the desired characteristic by it's Uuid
    • Enable notifications for the characteristic using characteristic.WriteClientCharacteristicConfigurationDescriptorAsync (using Notify, the device doesn't support Indicate)
    • Add a handler for the characteristic's ValueChanged event
    • In the event handler, read the motion data and store them in member variables
    • In the main loop, print out current values of the motion data member variables to stdout, then sleep for 17 ms (this gives ~59 updates per second)

    Can you please tell me if there's anything in my flow (e.g. the BluetoothLEDevice::FromIdAsync call) that could fail because of a consent prompt / no UI thread situation? If not, then is the comment in the official sample incorrect?

    Thank you very much
    Best regards
    Gene

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.