[connectivity-service] Extend the connectivity-api for Bluetooth scanning

Bug #1416731 reported by Sturm Flut
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
indicator-network (Ubuntu)
Triaged
Wishlist
Unassigned

Bug Description

One of my Ubuntu Touch app ideas is a Bluetooth Scanner. Bluetooth management functionality will have to be implemented anyways, and since Qt Bluetooth is not part of Ubuntu Touch images, I propose the extension of the connectivity-api.

The purpose of a Bluetooth scanner is to find all devices in range and gather as much additional information as possible, so we have to keep in mind which device types exist and which information we care about.

- Bluetooth Classic: At least the device MAC address and the contents of the “Class of Device” field are needed. If the device has a “pretty name” set, we want to know it, and if the adapter reports the signal strength with which the information was received this is important as well. We also want to query devices for the exact list of services they offer.

- Bluetooth Low Energy: Advertisements contain up to 31 bytes of arbitrary information, and the scanning device may actively query for up to 31 additional bytes. This information is important because it contains device names, UUIDs etc. The list of services offered can be retrieved using the Generic Attribute Profile (GATT), so the API should offer the necessary calls.

API calls and features

I propose the following API functions:

 - startScan() initiates a scan using the given technology. For Bluetooth Classic this would trigger an active scan, while for Bluetooth Low Energy it would set the device to continuous listening mode. Since it is unknown if and when the scan is finished, the call should return immediately and information is returned via callbacks. Depending on the hardware it may be possible to start scans for the different technologies at the same time.

- stopScan() stops an ongoing scan.

- queryServices() takes a device address and actively queries for a list of all offered services. The specification mentions quite short timeouts for many message types, so I am not sure if this call should block or use a callback.

Security and Privacy

A hostile app may calculate the location of a user from the list of iBeacons in range, and because of the short-range nature of Bluetooth this location will be quite accurate. I therefore propose that the first call to startScan() triggers a system popup informing the user about possible privacy implications and asking for permission.

summary: - Extend the connectivity-api for Bluetooth scanning
+ [connectivity-service] Extend the connectivity-api for Bluetooth
+ scanning
no longer affects: connectivity-api
Changed in indicator-network (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.