bluetooth: Add basic scanning to chrome://bluetooth-internals.

device/bluetooth/public/interfaces/adapter.mojom

Index: device/bluetooth/public/interfaces/adapter.mojom
diff --git a/device/bluetooth/public/interfaces/adapter.mojom b/device/bluetooth/public/interfaces/adapter.mojom
index 50042ae7a27e94750df7fc1c09967588dcf20f58..f57f9f90bd04cd8047e47cabcc5d0c6eae8a337e 100644
--- a/device/bluetooth/public/interfaces/adapter.mojom
+++ b/device/bluetooth/public/interfaces/adapter.mojom
@@ -39,10 +39,27 @@ struct AdapterInfo {
   bool discovering;
 };
 
-interface Adapter {
-  // Gets basic information about the adapter.
-  GetInfo() => (AdapterInfo info);
+interface DiscoverySession {
+  // Returns true if the session is active, false otherwise. If false, the
+  // adapter might still be discovering as there might still be other active
+  // sessions; this just means that this instance no longer has a say in
+  // whether or not discovery should continue. In this case, a new
+  // DiscoverySession should be started to make sure that device discovery
+  // continues.
+  IsActive() => (bool active);
+
+  // Requests this discovery session instance to stop. If this instance is
+  // active, the session will stop. After a successful invocation, the
+  // adapter may or may not stop device discovery, depending on whether or not
+  // other active discovery sessions are present. Users are highly encouraged
+  // to call this method to end a discovery session, instead of relying on
+  // disconnecting the message pipe, so that they can respond to the result.
+  // Returns true on success. Returns false if this session is inactive or an
+  // error occurs while stopping the session.
+  Stop() => (bool success);
+};
 
+interface Adapter {
   // Creates a GATT connection to the device with |address| and returns a
   // Device if the connection was succesful. The GATT connection is tied to the
   // the lifetime of the Device message pipe.
@@ -53,17 +70,24 @@ interface Adapter {
   // during a classic or low-energy scan.
   GetDevices() => (array<DeviceInfo> devices);
 
+  // Gets basic information about the adapter.
+  GetInfo() => (AdapterInfo info);
+
   // Sets the client that listens for the adapter's events.
   SetClient(AdapterClient client);

[dcheng, 2017/01/05 22:28:23]

Btw, is there ever a time when we'd want to create an Adapter interface with no
AdapterClient? It seems like these should be 1:1 right?

[mbrunson, 2017/01/06 01:18:56]

The bluetooth-internals is currently the only user of this service. In the
future, other clients may not care to receive events from AdapterClient, so I
thought it would be better to keep it optional in this case.

This mimics the current observer model of the BluetoothAdapter and its observer
interface where subscribing to these events are optional. Keeping it similar
will minimize the headache of clients who decide to switch to the Mojo-based
service.

[dcheng, 2017/01/06 02:45:50]

Would we create multiple BluetoothAdapter mojo impls? Or would all the things
connect to the same BluetoothAdapter mojo impl?

I'm just trying to understand the long-term plan here: in general, the
SetClient() pattern is one I try to discourage in IPC reviews if there is a
strong 1:1 relationship, because it requires a lot more checking (all the newly
added code needs to check for a non-null client), and it can make the control
flow harder to follow.

[mbrunson, 2017/01/06 03:09:41]

Every Adapter that is requested is a new strongly bound mojo impl[1]. They will
share the same underlying device::BluetoothAdapter instance though since the
device/bluetooth system uses the default bluetooth adapter hardware. So, there
could potentially be multiple impls with different configurations or no client
at all depending on the needs of the user.

[1]
https://cs.chromium.org/chromium/src/device/bluetooth/adapter_factory.cc?rcl=...

[dcheng, 2017/01/06 22:45:31]

Hmm. I'm not really sure what the best long-term approach here. Let's keep an
eye on this, and if it looks like it's going to be mostly used in a 1:1 context,
can we revisit the decision to have SetClient()? It makes all the methods more
complicated due to the null checking.

[mbrunson, 2017/01/06 23:14:37]

SGTM

+
+  // Requests the adapter to start a new discovery session. Returns null if
+  // session not created successfully.
+  StartDiscoverySession() => (DiscoverySession? session);
 };
 
 interface AdapterClient {
+  // Called when the discovering state of the adapter changes.
+  DiscoveringChanged(bool discovering);
+
   // Called the first time a device is discovered.
   DeviceAdded(DeviceInfo device);
 
-  // Called after the device hasn't been seen for 3 minutes.
-  DeviceRemoved(DeviceInfo device);
-
   // Called when one of the following properties of a device changes:
   //   Address, appearance, Bluetooth class, Inquiry RSSI, Inquiry TX Power,
   //   Service UUIDs, Connectionable state, Connection state, Pairing state,
@@ -72,6 +96,10 @@ interface AdapterClient {
   // guaranteed on ChromeOS or Linux. Because the RSSI is always changing,
   // it's very likely this will be called for each advertising packet.
   DeviceChanged(DeviceInfo device);
+
+  // Called after the device hasn't been seen for 3 minutes.
+  DeviceRemoved(DeviceInfo device);
+
 };
 
 interface AdapterFactory {