bluetooth: Implement simulateCentral

device/bluetooth/public/interfaces/test/fake_bluetooth.mojom

Index: device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
diff --git a/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom b/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
index 3ac2e80111de624cae06223d242c9205ea1bf6c9..9fe85e9853230bd6a604c59d0309ebcb94563bfc 100644
--- a/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
+++ b/device/bluetooth/public/interfaces/test/fake_bluetooth.mojom
@@ -9,6 +9,13 @@ module bluetooth.mojom;
 // devices, simulating GATT attributes and its descendants, and simulating
 // success and error responses.
 
+// Indicates the various states of LECentralObserverManager.
+enum LECentralObserverManagerState {
+  ABSENT,
+  POWERED_ON,
+  POWERED_OFF,
+};
+
 // FakeBluetooth allows clients to control the global Bluetooth state.
 interface FakeBluetooth {
   // Set it to indicate whether the platform supports BLE. For example, Windows
@@ -16,4 +23,21 @@ interface FakeBluetooth {
   // 10 is a platform that does support LE, even if there is no Bluetooth radio
   // available.
   SetLESupported(bool available) => ();
+
+  // Initializes a fake LECentralObserverManager with |state| as the initial
+  // state.
+  SimulateLECentralObserverManager(LECentralObserverManagerState state)
+      => (FakeLECentralObserverManager fake_manager);
+};
+
+// FakeLECentralObserverManager allows clients to simulate events that a device

[scheib, 2017/04/29 02:07:52]

This name is... hard. I don't have a better name yet, but ... we should simplify
it. Do we need both Central and Observer in the name? Maybe we use just one, and
in this comment indicate that in Bluetooth terms it is both?

[ortuno, 2017/05/01 06:09:04]

Currently we have an Adapter class that exposes all types of operations that can
be performed on the Adapter e.g. powering it on, changing it's name, scanning,
etc. But only Android and BlueZ expose many of these operations, which has led
us to have a bunch of NOTIMPLEMENTED or #if defined(...). To avoid that I think
we should split the interface into:

AdapterManager (ChromeOS only)
CentralObserverManager (All platforms) actual name tbd
PeripheralBroadcasterManager (All platforms) actual name tbd

Fake -> Because it's not the actual interface.
LE -> To make it easy to distinguish between LE and Classic interfaces. Though
if we are getting rid of classic support we might as well drop the "LE".
Central -> On the spec Central handles connection to devices
Observer -> On the spec Observer handles discovery of devices
Manager -> Because there are certain operations that aren't related to either
Central or Observer e.g. current state?

What do you think about: FakeRemoteManager? That would imply that eventually we
would have a RemoteManager and LocalManager interfaces. The former for
Central/Observer operation and the later for Peripheral/Broadcaster operations.

[scheib, 2017/05/01 18:16:59]

Splitting SGTM
Classic on ChromeOS is going to stay for a while, but perhaps we can move those
class names to be very profile specific, e.g. audio.

LE is OK. GATT may be more specific and better. But I do think we could omit any
tagging of things moving forward especially if we use terms that are from
GAP/GATT. We can start renaming classic types more, e.g. when needed call
something BluetoothClassicFoo, if we need differentiation.
I think the salient part is Central/Peripheral for our APIs. Broadcaster /
Observer seem to only describe if ad packets can be sent / received.

Do we ever expect to be a Central that isn't an Observer? No.
Do we ever expect to be a Peripheral that isn't a Broadcaster? No.

The chance of being a Central + Broadcaster and NOT a Peripheral seems very low
to me.

But, maybe we should split out classes for specifically each of the Central,
Peripheral, Observer, Broadcaster roles. That would keep APIs very focused. 

But, if we have the functionality of Central & Observer merged into one
interface I think we can omit the 'Observer' from the interface name.
Manager doesn't seem to help differentiate from other interface types - I would
omit it.

 
We do have some use of {Remote, Local} terminology already. Android APIs just
have attributes already mutable and able to be used as remote or local. Core
bluetooth has subclasses that enable attributes to be configured as local. In
Web Bluetooth I think we were heading down the {Remote, Local} terminology
route. All these seem fairly fine to me right now.


What do you think of:

in a bluetooth namespace:

Adapter
Observer - scanning
Broadcaster - advertizing
Central - connections
Peripheral - registering to serve a GATT tree
Service
LocalService
RemoteService
Characteristic
Local...

Fake versions have 'Fake' prefix.

[ortuno, 2017/05/02 01:14:10]

I agree on most points. I think Splitting Central/Observer is too much
granularity that is not really useful: as you said there will rarely be a
Central that isn't an Observer. Went with CentralFake. The code is much more
readable :)

+// in the Central/Observer role would receive as well as monitor the operations
+// performed by the device in the Central/Observer role.
+//
+// An LECentralObserverManger would allow its clients to perform the operations
+// and receive events for two roles defined by the Bluetooth Spec: Observer and
+// Central.
+// See Bluetooth 4.2 Vol 3 Part C 2.2.2 "Roles when Operation over
+// an LE Physical Transport".
+interface FakeLECentralObserverManager {
 };