bluetooth: Implement simulatePreconnectedPeripheral.

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

 // Copyright 2017 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 module bluetooth.mojom;
 
 // FakeBluetooth and its related interfaces allow clients to control the global
 // Bluetooth State as well as simulate Bluetooth events including finding new
 // devices, simulating GATT attributes and its descendants, and simulating
 // success and error responses.
@@ skipping 20 matching lines @@
 // FakeCentral allows clients to simulate events that a device in the
 // Central/Observer role would receive as well as monitor the operations
 // performed by the device in the Central/Observer role.
 //
 // A "Central" interface would allow its clients to receive advertising events
 // and initiate connections to peripherals i.e. operations of two roles
 // defined by the Bluetooth Spec: Observer and Central.
 // See Bluetooth 4.2 Vol 3 Part C 2.2.2 "Roles when Operating over an
 // LE Physical Transport".
 interface FakeCentral {
+  // Simulates a peripheral with |address| and |name| that has already
+  // been connected to the system. If the peripheral existed already it
+  // updates its name.
+  //
+  // Platforms offer methods to retrieve devices that have already been
+  // connected to the system or weren't connected through the UA e.g. a user
+  // connected a peripheral through the system's settings. This method is
+  // intended to simulate peripherals that those methods would return.
+  SimulatePreconnectedPeripheral(string address, string name) => ();

[dcheng, 2017/05/05 06:18:48]

Is there any structure to either of these fields? The ARC++ Bluetooth code
passes address as a fixed-length byte buffer IIRC. Can we/should we be doing
that here?

IIRC, using more structured identifiers was a request from palmer@ as well in
other parts of the web blutooth mojom interface.

[ortuno, 2017/05/08 01:08:13]

They are MAC Address so "00:00:00:00:00:00".
It's unclear to me why we pass the address as an array for Arc++. Most users of
the device/bluetooth need the address in form of a string e.g. extensions,
system tray, etc.

We could add a struct and validate the format but I think the benefit,
validating test addresses, might not be worth it.

[dcheng, 2017/05/09 04:20:07]

Does this show up in other parts of the mojo interface? It's more about using a
consistent type across both non-test and test interfaces, and making sure that
we're handling them uniformly.

[ortuno, 2017/05/09 04:25:12]

Besides Arc++, the only Bluetooth related Mojo interface we currently have is
web_bluetooth.mojom which does not use the address (it uses WebBluetoothDeviceId
which as you point out palmer@ requested). 

There is a chance the eventual BT Mojo interface/service would use a type for
it.

 };