touch-packages team mailing list archive

[Antti Kaijanmäki <antti.kaijanmaki@xxxxxxxxxxxxx>]

** Also affects: indicator-network (Ubuntu)
   Importance: Undecided
       Status: New

** Summary changed:

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

** No longer affects: connectivity-api

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to indicator-network in
Ubuntu.
https://bugs.launchpad.net/bugs/1416731

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

Status in indicator-network package in Ubuntu:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1416731/+subscriptions