odejesush
commented
5 years ago The services that you include in the filters for requestDevice() are the services that will be used to filter out devices when a scan is performed. As long as you include the custom defined GATT service UUID, and it is a valid UUID that is not in the blocklist, then the device should be shown in the user prompt.
The line that you referenced from the spec is from step 6.2 of the scan for devices algorithm. If we follow the steps backwards, the set of Service UUIDs that is used in the algorithm comes from the requiredServiceUUIDs set in step 7 of the request Bluetooth devices algorithm. The requiredServiceUUIDs is the result of canonicalizing the filters passed into requestDevice(), performed in step 2.4.3 of the request Bluetooth devices algorithm.
The canonicalizing algorithm makes sure that the services included in the filter are valid in step 3. It does this by first attempting to grab the service UUID given a service name, or if a UUID is given, it makes sure that it's a valid UUID. After this step, it checks if the service UUID is in the blocklist and throws a SecurityError if it is. Hopefully this explanation makes sense.
First, the source code for the BLE Peripheral Simulator is a tremendous resource for anyone investigating Web Bluetooth. https://github.com/WebBluetoothCG/ble-test-peripheral-android
There is a an approved list of GATT Services. https://www.bluetooth.com/specifications/gatt/services/
When I modified the Android source code to use a custom defined GATT service (easy to do by simply specifying your own UUID in the Android code) pairing from the web page to the Android app running the GATT sever fails.
The Web Bluetooth documentation does state, "If device’s advertised Service UUIDs have a non-empty intersection with the set of Service UUIDs, add device to result and abort these sub-steps [for pairing]."
Does this mean only services in the approved GATT list are supported? If so, what is the rational? It seems that such a restriction would limit innovation.