[CrOS Tether] Create BleScanner, a class which scan BLE advertisements and identifies nearby device…

[CrOS Tether] Create BleScanner, a class which scan BLE advertisements and identifies nearby devices.

This class provides an API for registering or unregistering RemoteDevices. As long as at least one RemoteDevice is registered, a discovery session is active. If an advertisement from a registered RemoteDevice is scanned, observers are notified.

BUG=672263
Committed: https://crrev.com/04cac696114d80e0486f3e0292e448faf38c227e
Cr-Commit-Position: refs/heads/master@{#441484}

[Kyle Horimoto, 2016-12-29 23:24:50]

khorimoto@chromium.org changed reviewers:
+ hansberry@chromium.org, scheib@chromium.org

[Kyle Horimoto, 2016-12-29 23:24:50]

hansberry@ for tether review.
scheib@ review needed because of new dependency on device/bluetooth.

[Ryan Hansberry, 2017-01-04 00:01:04]

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
File chromeos/components/tether/ble_scanner.cc (right):

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:24: const int kMinDiscoveryRSSI = -90;
nit: briefly comment on where this number comes from.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:25: const size_t
kMinNumBytesInServiceData = 4;
nit: make this (2 * cryptauth::EidGenerator::kNumBytesInEidValue), or at least
give a short comment explaining where this comes from.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:77: // concurrent advertisements
cannot exceed the maximum number of conrurrent
concurrent*

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:106: iter !=
registered_devices_.end(); iter++) {
nit: iterator incrementation should generally be done using the prefix ++, i.e.
'++iter'.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:118: for (auto iter =
registered_devices_.begin();
super-nit: I find that 'it' is the more common short name for iterator.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:119: iter !=
registered_devices_.end(); iter++) {
Same comment about prefix incrementing.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:183: PA_LOG(INFO) << "Initializing
Bluetooth adapter.";
Should we be using ProximityAuth logging?

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:214: std::move(filter),
base::Bind(&BleScanner::OnDiscoverySessionStarted,
This needs to be placed on another line (the 2nd argument).

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:250: return;
nit: add a log.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:279: }
nit: add a log for when a device cannot be identified from the advertisement

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
File chromeos/components/tether/ble_scanner.h (right):

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.h:51: device::BluetoothDevice* device)
override;
nit: because there are mixed mentions of RemoteDevices and BluetoothDevices
throughout this class, I think it would moderately improve readability to
clarify all BluetoothDevices as 'bluetooth_device' as opposed to simply
'device'. Otherwise readers can become confused what kind of *Device each
'device' variable is. 

I also personally find it confusing that OnReceivedAdvertisementFromDevice()'s
BluetoothDevice param is 'bluetooth_device', but other methods' BluetoothDevice
params are named 'device'.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.h:104: bool initializing_adapter_;
nit: can you prefix this and 'initializing_discovery_session_' with 'is_'?

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.h:110:
std::vector<cryptauth::RemoteDevice> registered_devices_;
Similar comment to my nit above: this would be better as
'registered_remote_devices_'.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
File chromeos/components/tether/ble_scanner_unittest.cc (right):

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:57: class
MockServiceDataBluetoothDevice : public device::MockBluetoothDevice {
nit: Maybe rename this MockBluetoothDeviceWithServiceData?

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:88: const std::string
fake_beacon_seed1_data = "fakeBeaconSeed1Data";
nit: instead of '1' and '2', used 'current' and 'adjacent', respectively.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:89: const int64_t
fake_beacon_seed1_start_ms = 1000L;
Directly 'current_eid_start_ms' and etc. instead of essentially redeclaring
them.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:158: return
reinterpret_cast<MockServiceDataBluetoothDevice*>(device)
For my own learning: Why did you choose reinterpret_cast instead of static_cast?

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:204:
base::WrapUnique(test_delegate_), mock_eid_generator_.get(),
nit: place this arg on a separate line.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:226:
ASSERT_TRUE(last_get_adapter_callback);
Is there any kind of ASSERT_NOT_NULL? This reads like it's a boolean. Not a big
deal if not.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:249: EXPECT_EQ(-90,
observed_rssi);
Please use the constant defined in BleScanner.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:251: // Now, ensure that both
a callback and errback were pased.
passed*

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:369: TEST_F(BleScannerTest,
TestDiscovery) {
nit: I think it would be very valuable to split this test up. It's quite large,
and the values of calls like mock_eid_generator_->num_identify_calls() are
affected by previous tests, which means you need to understand how all these
separate tests interact in order to understand this test method as a whole.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:393:
EXPECT_FALSE(mock_observer_->GetNumCalls());
Please use EXPECT_EQ(0, ...) instead, for all these calls that return numbers.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:414: // device corresponding
to
Please complete this comment.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:529:
EXPECT_CALL(*mock_adapter_, IsPowered())
This is pretty difficult to read. I can't easily tell where each of these
different calls will happen. Is it possible to explicitly pepper these
throughout this test?

[Kyle Horimoto, 2017-01-04 18:35:44]

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
File chromeos/components/tether/ble_scanner.cc (right):

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:24: const int kMinDiscoveryRSSI = -90;
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> nit: briefly comment on where this number comes from.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:25: const size_t
kMinNumBytesInServiceData = 4;
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> nit: make this (2 * cryptauth::EidGenerator::kNumBytesInEidValue), or at least
> give a short comment explaining where this comes from.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:77: // concurrent advertisements
cannot exceed the maximum number of conrurrent
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> concurrent*

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:106: iter !=
registered_devices_.end(); iter++) {
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> nit: iterator incrementation should generally be done using the prefix ++,
i.e.
> '++iter'.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:118: for (auto iter =
registered_devices_.begin();
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> super-nit: I find that 'it' is the more common short name for iterator.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:119: iter !=
registered_devices_.end(); iter++) {
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> Same comment about prefix incrementing.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:183: PA_LOG(INFO) << "Initializing
Bluetooth adapter.";
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> Should we be using ProximityAuth logging?

For now, yes. We may want to come up with a CrOS Tether logger at some point,
but I'm not going to do it in this CL.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:214: std::move(filter),
base::Bind(&BleScanner::OnDiscoverySessionStarted,
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> This needs to be placed on another line (the 2nd argument).

Nope, the Chromium lint tool did this.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:250: return;
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> nit: add a log.

I don't want to add a log here since it would be very spammy. It would be
printed for literally every single BLE device that is advertising nearby the
device.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.cc:279: }
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> nit: add a log for when a device cannot be identified from the advertisement 

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
File chromeos/components/tether/ble_scanner.h (right):

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.h:51: device::BluetoothDevice* device)
override;
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> nit: because there are mixed mentions of RemoteDevices and BluetoothDevices
> throughout this class, I think it would moderately improve readability to
> clarify all BluetoothDevices as 'bluetooth_device' as opposed to simply
> 'device'. Otherwise readers can become confused what kind of *Device each
> 'device' variable is. 
> 
> I also personally find it confusing that OnReceivedAdvertisementFromDevice()'s
> BluetoothDevice param is 'bluetooth_device', but other methods'
BluetoothDevice
> params are named 'device'.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.h:104: bool initializing_adapter_;
On 2017/01/04 00:01:03, Ryan Hansberry wrote:
> nit: can you prefix this and 'initializing_discovery_session_' with 'is_'? 

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner.h:110:
std::vector<cryptauth::RemoteDevice> registered_devices_;
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> Similar comment to my nit above: this would be better as
> 'registered_remote_devices_'.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
File chromeos/components/tether/ble_scanner_unittest.cc (right):

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:57: class
MockServiceDataBluetoothDevice : public device::MockBluetoothDevice {
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> nit: Maybe rename this MockBluetoothDeviceWithServiceData?

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:88: const std::string
fake_beacon_seed1_data = "fakeBeaconSeed1Data";
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> nit: instead of '1' and '2', used 'current' and 'adjacent', respectively.

I'm going to keep it as 1 and 2. There is no notion of current or adjacent for
the seeds themselves, only for the EidData.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:89: const int64_t
fake_beacon_seed1_start_ms = 1000L;
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> Directly 'current_eid_start_ms' and etc. instead of essentially redeclaring
> them.

Ditto.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:158: return
reinterpret_cast<MockServiceDataBluetoothDevice*>(device)
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> For my own learning: Why did you choose reinterpret_cast instead of
static_cast?

reinterpret_cast should be used when we are converting a type to another version
of the same type (i.e., MockBluetoothDeviceWithServiceData is a
MockBluetoothDevice). static_cast should be used when you are changing the
interpretation of the bytes (e.g., when casting a long to an int).

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:204:
base::WrapUnique(test_delegate_), mock_eid_generator_.get(),
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> nit: place this arg on a separate line.

Same - this is what the Chromium lint tool chose.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:226:
ASSERT_TRUE(last_get_adapter_callback);
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> Is there any kind of ASSERT_NOT_NULL? This reads like it's a boolean. Not a
big
> deal if not.

No, this is the conventional approach within Chromium.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:249: EXPECT_EQ(-90,
observed_rssi);
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> Please use the constant defined in BleScanner.

That is an implementation detail of the class, so I don't want to expose it
publicly. I used a constant kExpectedDiscoveryRSSI for this test.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:251: // Now, ensure that both
a callback and errback were pased.
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> passed*

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:369: TEST_F(BleScannerTest,
TestDiscovery) {
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> nit: I think it would be very valuable to split this test up. It's quite
large,
> and the values of calls like mock_eid_generator_->num_identify_calls() are
> affected by previous tests, which means you need to understand how all these
> separate tests interact in order to understand this test method as a whole.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:393:
EXPECT_FALSE(mock_observer_->GetNumCalls());
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> Please use EXPECT_EQ(0, ...) instead, for all these calls that return numbers.

EXPECT_TRUE/EXPECT_FALSE are the convention in Chromium for these cases.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:414: // device corresponding
to
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> Please complete this comment.

Done.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:529:
EXPECT_CALL(*mock_adapter_, IsPowered())
On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> This is pretty difficult to read. I can't easily tell where each of these
> different calls will happen. Is it possible to explicitly pepper these
> throughout this test?

That's not valid to do within GoogleMock.

Relevant information from [1] is copied below:
Google Mock requires expectations to be set before the mock functions are
called, otherwise the behavior is undefined.

[1]
https://github.com/google/googletest/blob/master/googlemock/docs/ForDummies.md

[Ryan Hansberry, 2017-01-04 20:02:20]

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
File chromeos/components/tether/ble_scanner_unittest.cc (right):

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:89: const int64_t
fake_beacon_seed1_start_ms = 1000L;
On 2017/01/04 18:35:43, Kyle Horimoto wrote:
> On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> > Directly 'current_eid_start_ms' and etc. instead of essentially redeclaring
> > them.
> 
> Ditto.

I understand your reasoning for not renaming the seeds to current or adjacent,
but why not set variables like 'fake_beacon_seed1_start_ms' to
'current_eid_start_ms' instead of reusing the literal value 1000?

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:158: return
reinterpret_cast<MockServiceDataBluetoothDevice*>(device)
On 2017/01/04 18:35:44, Kyle Horimoto wrote:
> On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> > For my own learning: Why did you choose reinterpret_cast instead of
> static_cast?
> 
> reinterpret_cast should be used when we are converting a type to another
version
> of the same type (i.e., MockBluetoothDeviceWithServiceData is a
> MockBluetoothDevice). static_cast should be used when you are changing the
> interpretation of the bytes (e.g., when casting a long to an int).

Thanks!

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:204:
base::WrapUnique(test_delegate_), mock_eid_generator_.get(),
On 2017/01/04 18:35:43, Kyle Horimoto wrote:
> On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> > nit: place this arg on a separate line.
> 
> Same - this is what the Chromium lint tool chose.

My bad, still getting used to the style.

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:529:
EXPECT_CALL(*mock_adapter_, IsPowered())
On 2017/01/04 18:35:44, Kyle Horimoto wrote:
> On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> > This is pretty difficult to read. I can't easily tell where each of these
> > different calls will happen. Is it possible to explicitly pepper these
> > throughout this test?
> 
> That's not valid to do within GoogleMock.
> 
> Relevant information from [1] is copied below:
> Google Mock requires expectations to be set before the mock functions are
> called, otherwise the behavior is undefined.
> 
> [1]
> https://github.com/google/googletest/blob/master/googlemock/docs/ForDummies.md

Thanks for the link, that's really helpful.

[Kyle Horimoto, 2017-01-04 20:06:57]

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
File chromeos/components/tether/ble_scanner_unittest.cc (right):

https://codereview.chromium.org/2604063003/diff/20001/chromeos/components/tet...
chromeos/components/tether/ble_scanner_unittest.cc:89: const int64_t
fake_beacon_seed1_start_ms = 1000L;
On 2017/01/04 20:02:20, Ryan Hansberry wrote:
> On 2017/01/04 18:35:43, Kyle Horimoto wrote:
> > On 2017/01/04 00:01:04, Ryan Hansberry wrote:
> > > Directly 'current_eid_start_ms' and etc. instead of essentially
redeclaring
> > > them.
> > 
> > Ditto.
> 
> I understand your reasoning for not renaming the seeds to current or adjacent,
> but why not set variables like 'fake_beacon_seed1_start_ms' to
> 'current_eid_start_ms' instead of reusing the literal value 1000?

Done.

[Ryan Hansberry, 2017-01-04 20:09:17]

The CQ bit was checked by hansberry@chromium.org

[Ryan Hansberry, 2017-01-04 20:09:17]

lgtm

lgtm

[commit-bot: I haz the power, 2017-01-04 20:09:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-04 20:14:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-04 20:14:25]

Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[scheib, 2017-01-04 20:32:00]

device/bluetooth DEPS LGTM

[Kyle Horimoto, 2017-01-04 21:02:07]

The CQ bit was checked by khorimoto@chromium.org

[Kyle Horimoto, 2017-01-04 21:02:07]

The patchset sent to the CQ was uploaded after l-g-t-m from scheib@chromium.org,
hansberry@chromium.org
Link to the patchset: https://codereview.chromium.org/2604063003/#ps80001
(title: "Add missing dependency.")

[commit-bot: I haz the power, 2017-01-04 21:02:26]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-04 22:16:27]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1483563727034390,
"parent_rev": "27ad279f64b0755eff4f23aa25be47c9f098c39e", "commit_rev":
"446fc5ecb65fe841c9e3f825dfc517a611db63c3"}

[commit-bot: I haz the power, 2017-01-04 22:17:00]

Description was changed from

==========
[CrOS Tether] Create BleScanner, a class which scan BLE advertisements and
identifies nearby devices.

This class provides an API for registering or unregistering RemoteDevices. As
long as at least one RemoteDevice is registered, a discovery session is active.
If an advertisement from a registered RemoteDevice is scanned, observers are
notified.

BUG=672263
==========

to

==========
[CrOS Tether] Create BleScanner, a class which scan BLE advertisements and
identifies nearby devices.

This class provides an API for registering or unregistering RemoteDevices. As
long as at least one RemoteDevice is registered, a discovery session is active.
If an advertisement from a registered RemoteDevice is scanned, observers are
notified.

BUG=672263

Review-Url: https://codereview.chromium.org/2604063003
==========

[commit-bot: I haz the power, 2017-01-04 22:17:01]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2017-01-04 22:20:09]

Description was changed from

==========
[CrOS Tether] Create BleScanner, a class which scan BLE advertisements and
identifies nearby devices.

This class provides an API for registering or unregistering RemoteDevices. As
long as at least one RemoteDevice is registered, a discovery session is active.
If an advertisement from a registered RemoteDevice is scanned, observers are
notified.

BUG=672263

Review-Url: https://codereview.chromium.org/2604063003
==========

to

==========
[CrOS Tether] Create BleScanner, a class which scan BLE advertisements and
identifies nearby devices.

This class provides an API for registering or unregistering RemoteDevices. As
long as at least one RemoteDevice is registered, a discovery session is active.
If an advertisement from a registered RemoteDevice is scanned, observers are
notified.

BUG=672263

Committed: https://crrev.com/04cac696114d80e0486f3e0292e448faf38c227e
Cr-Commit-Position: refs/heads/master@{#441484}
==========

[commit-bot: I haz the power, 2017-01-04 22:20:10]

Patchset 5 (id:??) landed as
https://crrev.com/04cac696114d80e0486f3e0292e448faf38c227e
Cr-Commit-Position: refs/heads/master@{#441484}