bluetooth: Replace old advertised uuids

bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs.

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items (http://crrev.com/2210873003)
 [3] Only add new devices, connected devices and devices that changed
     (http://crrev.com/2217573002)

BUG=508904
Committed: https://crrev.com/8a06300cf9c86285d6f8f3b789549614fd19463e
Cr-Commit-Position: refs/heads/master@{#410541}

[ortuno, 2016-08-02 22:59:36]

Description was changed from

==========
bluetooth: Notify of changed device whenever we get an advertisement

This matches bluez and to allows users of the API to know about advertising
events.

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

TODO: docs

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2]
 [3]

BUG=508904
==========

[ortuno, 2016-08-04 01:43:58]

Description was changed from

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

TODO: docs

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2]
 [3]

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2]
 [3]

BUG=508904
==========

[ortuno, 2016-08-04 01:46:29]

Description was changed from

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2]
 [3]

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items on desktop (TODO)
 [3] Allow updates on chooser items on android (TODO)
 [4] Add devices on DeviceChanged rather than OnDeviceAdded.

BUG=508904
==========

[ortuno, 2016-08-04 01:46:40]

Description was changed from

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items on desktop (TODO)
 [3] Allow updates on chooser items on android (TODO)
 [4] Add devices on DeviceChanged rather than OnDeviceAdded.

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items on desktop (TODO)
 [3] Allow updates on chooser items on android (TODO)
 [4] Add devices on DeviceChanged rather than OnDeviceAdded (TODO)

BUG=508904
==========

[ortuno, 2016-08-04 01:53:44]

Description was changed from

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items on desktop (TODO)
 [3] Allow updates on chooser items on android (TODO)
 [4] Add devices on DeviceChanged rather than OnDeviceAdded (TODO)

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items
 [3] Add devices on DeviceChanged rather than OnDeviceAdded (TODO)

BUG=508904
==========

[ortuno, 2016-08-04 01:54:03]

Description was changed from

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items
 [3] Add devices on DeviceChanged rather than OnDeviceAdded (TODO)

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items (TODO)
 [3] Add devices on DeviceChanged rather than OnDeviceAdded (TODO)

BUG=508904
==========

[ortuno, 2016-08-04 01:54:13]

The CQ bit was checked by ortuno@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-04 01:54:49]

Dry run: 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, 2016-08-04 03:18:04]

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

[commit-bot: I haz the power, 2016-08-04 03:18:04]

Dry run: This issue passed the CQ dry run.

[ortuno, 2016-08-04 17:24:20]

Description was changed from

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items (TODO)
 [3] Add devices on DeviceChanged rather than OnDeviceAdded (TODO)

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items (http://crrev.com/2210873003)
 [3] Add devices on DeviceChanged rather than OnDeviceAdded (TODO)

BUG=508904
==========

[ortuno, 2016-08-04 19:52:19]

Description was changed from

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items (http://crrev.com/2210873003)
 [3] Add devices on DeviceChanged rather than OnDeviceAdded (TODO)

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items (http://crrev.com/2210873003)
 [3] Only add new devices, connected devices and devices that changed
     (http://crrev.com/2217573002)

BUG=508904
==========

[ortuno, 2016-08-04 19:56:07]

ortuno@chromium.org changed reviewers:
+ scheib@chromium.org

[ortuno, 2016-08-04 19:56:09]

scheib: PTAL

[scheib, 2016-08-05 18:49:31]

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_adapter_android.cc (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_android.cc:206:
FOR_EACH_OBSERVER(BluetoothAdapter::Observer, observers_,
Only notify if UUIDs are different.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_adapter_mac.mm (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_mac.mm:519:
FOR_EACH_OBSERVER(BluetoothAdapter::Observer, observers_,
Why dropping the comment?

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_adapter_unittest.cc (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_unittest.cc:624: TEST_F(BluetoothTest,
DiscoverLowEnergyDeviceWithUpdatedUUIDs) {
Let's add another test that discovering the same device twice, with the same
UUIDs doesn't send a device changed. Android should be able to pass.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_device.h (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_device.h:293: // For non-connected Low Energy Devices
this returns the latest advertised
optional:
* Use some bullets.
* There are a few cases described.
* I at least like bullets.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_device.h:576: std::unordered_set<BluetoothUUID,
BluetoothUUIDHash> advertised_uuids_;
optional... we already have the code to gather all UUIDs from services once
discovered. I recommend changing this to just 'uuids_', and upon service
discovery complete gathering all uuids from services and storing here. GetUUIDs
then is then cheaper with the same amount of code -- but we expect it to be
called fairly often as client code tries to understand devices.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_device_android.h (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_device_android.h:53: void UpdateAdvertisedUUIDs(
Why drop the bool return value? We shouldn't re-notify if UUIDs haven't changed.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm:70:
CBCentralManagerScanOptionAllowDuplicatesKey :
Add a comment explaining why CBCentralManagerScanOptionAllowDuplicatesKey.

Also, we should use it only if necessary -- do we know that devices with
different UUIDs will not cause another event? The eddystone beacon can help us
manually test right?

[ortuno, 2016-08-05 22:58:48]

The CQ bit was checked by ortuno@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-05 22:59:16]

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

[ortuno, 2016-08-05 23:00:17]

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_adapter_android.cc (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_android.cc:206:
FOR_EACH_OBSERVER(BluetoothAdapter::Observer, observers_,
On 2016/08/05 at 18:49:31, scheib wrote:
> Only notify if UUIDs are different.

This specific change has little to do with the advertised UUIDs. This is
changing DeviceChanged to be called for *every* new advertisement. This is what
will allow the chooser to know if the device is actually around. For example:

1. Turn on Playbulb
2. requestDevice()
3. The chooser will:
   1. Add any connected devices that match
   2. Start a scan
   3. Add devices as DeviceAdded and DeviceChanged are called.
4. See Playbulb.

So far so good.

1. Turn off Playbulb
2. requestDevice()
3. The chooser will do the same steps as above but the device won't get added to
the chooser because DeviceChanged was never called so the device can't possibly
be around.
4. Users are happy because they don't see the device they know is no longer
around.

If we were to only notify when the UUIDs change we would no longer be able to
perform step 3 and the Playbulb will still show up in the chooser even though
it's not on.

Besides the reason stated above. CreateOrUpdateDeviceOnScan will also eventually
update rssi. rssi changes for every single packet so we would basically notify
for every packet regardless of whether services have changed or not.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_adapter_mac.mm (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_mac.mm:519:
FOR_EACH_OBSERVER(BluetoothAdapter::Observer, observers_,
On 2016/08/05 at 18:49:31, scheib wrote:
> Why dropping the comment?

See response on bluetooth_adapter_android.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_adapter_unittest.cc (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_unittest.cc:624: TEST_F(BluetoothTest,
DiscoverLowEnergyDeviceWithUpdatedUUIDs) {
On 2016/08/05 at 18:49:31, scheib wrote:
> Let's add another test that discovering the same device twice, with the same
UUIDs doesn't send a device changed. Android should be able to pass.

I think that should also result in DeviceChanged. See response in
bluetooth_adapter_android.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_device.h (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_device.h:293: // For non-connected Low Energy Devices
this returns the latest advertised
On 2016/08/05 at 18:49:31, scheib wrote:
> optional:
> * Use some bullets.
> * There are a few cases described.
> * I at least like bullets.

Done.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_device_android.h (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_device_android.h:53: void UpdateAdvertisedUUIDs(
On 2016/08/05 at 18:49:31, scheib wrote:
> Why drop the bool return value? We shouldn't re-notify if UUIDs haven't
changed.

We will notify for each advertisement. So the bool returned by this doesn't help
anymore.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm:70:
CBCentralManagerScanOptionAllowDuplicatesKey :
On 2016/08/05 at 18:49:31, scheib wrote:
> Add a comment explaining why CBCentralManagerScanOptionAllowDuplicatesKey.
> 
> Also, we should use it only if necessary -- do we know that devices with
different UUIDs will not cause another event? The eddystone beacon can help us
manually test right?

This has to do with the reason stated in bluetooth_adapter_android and not
necessarily with the UUIDs changing. We want to know of each advertisement
packet so that we can know if the device is still around. If we were to remove
this then we would only get notified once and we won't know if the device is
still around.

Also, if we remove this option we would only get notified of *new* services and
not of services being removed. So in the Eddystone case:

1. Adv URL -> Get notified because of new service.
2. Adv config service -> Get notified because of new service.
3. Adv URL again -> No notification because of old service.

[scheib, 2016-08-06 00:21:41]

Thanks, I understand more now! LGTM with comments:

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_adapter_android.cc (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_android.cc:206:
FOR_EACH_OBSERVER(BluetoothAdapter::Observer, observers_,
On 2016/08/05 23:00:16, ortuno wrote:
> On 2016/08/05 at 18:49:31, scheib wrote:
> > Only notify if UUIDs are different.
> 
> This specific change has little to do with the advertised UUIDs. This is
> changing DeviceChanged to be called for *every* new advertisement. This is
what
> will allow the chooser to know if the device is actually around. For example:
> 
> 1. Turn on Playbulb
> 2. requestDevice()
> 3. The chooser will:
>    1. Add any connected devices that match
>    2. Start a scan
>    3. Add devices as DeviceAdded and DeviceChanged are called.
> 4. See Playbulb.
> 
> So far so good.
> 
> 1. Turn off Playbulb
> 2. requestDevice()
> 3. The chooser will do the same steps as above but the device won't get added
to
> the chooser because DeviceChanged was never called so the device can't
possibly
> be around.
> 4. Users are happy because they don't see the device they know is no longer
> around.
> 
> If we were to only notify when the UUIDs change we would no longer be able to
> perform step 3 and the Playbulb will still show up in the chooser even though
> it's not on.
> 
> Besides the reason stated above. CreateOrUpdateDeviceOnScan will also
eventually
> update rssi. rssi changes for every single packet so we would basically notify
> for every packet regardless of whether services have changed or not.

OK, thanks for explanation -- Document on adapter::Observer that DeviceChanged
is expected for all advertisements - even for stable values then? Or, make
another notification?

https://codereview.chromium.org/2205693003/diff/120001/device/bluetooth/bluet...
File device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm (right):

https://codereview.chromium.org/2205693003/diff/120001/device/bluetooth/bluet...
device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm:68: // of each
new advertisement packet.
Good, but follow through with why we need to see each packet. (cite the comment
you'll at too Observer::DeviceChanged)

[commit-bot: I haz the power, 2016-08-06 01:14:43]

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

[commit-bot: I haz the power, 2016-08-06 01:14:44]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[ortuno, 2016-08-08 22:55:40]

The CQ bit was checked by ortuno@chromium.org

[ortuno, 2016-08-08 22:55:40]

The patchset sent to the CQ was uploaded after l-g-t-m from scheib@chromium.org
Link to the patchset: https://codereview.chromium.org/2205693003/#ps140001
(title: "Improve comments")

[commit-bot: I haz the power, 2016-08-08 22:56:20]

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

[ortuno, 2016-08-08 22:56:39]

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_adapter_android.cc (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_android.cc:206:
FOR_EACH_OBSERVER(BluetoothAdapter::Observer, observers_,
On 2016/08/06 at 00:21:41, scheib wrote:
> On 2016/08/05 23:00:16, ortuno wrote:
> > On 2016/08/05 at 18:49:31, scheib wrote:
> > > Only notify if UUIDs are different.
> > 
> > This specific change has little to do with the advertised UUIDs. This is
> > changing DeviceChanged to be called for *every* new advertisement. This is
what
> > will allow the chooser to know if the device is actually around. For
example:
> > 
> > 1. Turn on Playbulb
> > 2. requestDevice()
> > 3. The chooser will:
> >    1. Add any connected devices that match
> >    2. Start a scan
> >    3. Add devices as DeviceAdded and DeviceChanged are called.
> > 4. See Playbulb.
> > 
> > So far so good.
> > 
> > 1. Turn off Playbulb
> > 2. requestDevice()
> > 3. The chooser will do the same steps as above but the device won't get
added to
> > the chooser because DeviceChanged was never called so the device can't
possibly
> > be around.
> > 4. Users are happy because they don't see the device they know is no longer
> > around.
> > 
> > If we were to only notify when the UUIDs change we would no longer be able
to
> > perform step 3 and the Playbulb will still show up in the chooser even
though
> > it's not on.
> > 
> > Besides the reason stated above. CreateOrUpdateDeviceOnScan will also
eventually
> > update rssi. rssi changes for every single packet so we would basically
notify
> > for every packet regardless of whether services have changed or not.
> 
> OK, thanks for explanation -- Document on adapter::Observer that DeviceChanged
is expected for all advertisements - even for stable values then? Or, make
another notification?

Added a comment to explicitly mention that DeviceChanged is essentially called
for every advertisement packet because the RSSI is always changing. Regarding
adding a new notification: Our hands are tied by BlueZ here. I thought through a
couple of options to implement given the BlueZ restrictions:

Say we wanted to introduce a really useful function that tells us everything
that's included in an adv packet. There are two reasons why this wouldn't work.
(1) We don't have access to each packet so we wouldn't know what's in each
packet so we would tell the client the wrong information. (2) BlueZ doesn't
update all properties at once, it notifies of each change so for example a
device that is alternating names and service data:

 1. Notify of Name change.
 2. Notify of RSSI change.
 3. Notify of Service Data change.

We would have to implement some sort of bounce mechanism so that we can group
the changes for each advertisement.

Say we wanted to introduce a simple notification for when adv's are received:

1. AdvReceived called when RSSI changes -> We have no guarantee of the order in
which properties are updated so clients can't know if the information is up to
date when the get AdvReceived. For example

   1. Device advertises "0x01" as adv data and we get RSSI: -100
   2. BlueZ calls PropertyChanged with RSSI and we call AdvReceived.
   3. Client sees AdvReceived and tries to get the advertisement data but sees
no data :(
   4. BlueZ calls PropertyChanged with Adv Data "0x01".

2. AdvReceived called when RSSI, TxPower, Device Name, or any of the other adv
related properties changes -> We would call AdvReceived for each of these that
change which would confuse clients.

   1. Device advertises "0x01" as adv data and we get RSSI: -100
   2. Bluez calls PropertyChanged with RSSI and we call AdvReceived.
   3. BlueZ calls PropertyChanged with Adv Data and we call AdvReceived.
   4. BlueZ calls PropertyChanged with Name and we call AdvReceived.
   ... and so on for each property that changed in the adv packet.

After thinking through this I think the best solution would be for BlueZ to just
have an Advertisement Packet property that's just raw bytes. Then we can parse
it an update the properties all at once.

Anyway, I think any of those options needs a bigger refactoring. We can open an
issue if we feel that is important.

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
File device/bluetooth/bluetooth_device.h (right):

https://codereview.chromium.org/2205693003/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_device.h:576: std::unordered_set<BluetoothUUID,
BluetoothUUIDHash> advertised_uuids_;
On 2016/08/05 at 18:49:31, scheib wrote:
> optional... we already have the code to gather all UUIDs from services once
discovered. I recommend changing this to just 'uuids_', and upon service
discovery complete gathering all uuids from services and storing here. GetUUIDs
then is then cheaper with the same amount of code -- but we expect it to be
called fairly often as client code tries to understand devices.

Done. Forgot to mark this done the first time.

https://codereview.chromium.org/2205693003/diff/120001/device/bluetooth/bluet...
File device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm (right):

https://codereview.chromium.org/2205693003/diff/120001/device/bluetooth/bluet...
device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm:68: // of each
new advertisement packet.
On 2016/08/06 at 00:21:41, scheib wrote:
> Good, but follow through with why we need to see each packet. (cite the
comment you'll at too Observer::DeviceChanged)

Done.

[commit-bot: I haz the power, 2016-08-08 23:07:02]

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

[commit-bot: I haz the power, 2016-08-08 23:07:04]

Try jobs failed on following builders:
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)

[ortuno, 2016-08-08 23:22:48]

The CQ bit was checked by ortuno@chromium.org

[commit-bot: I haz the power, 2016-08-08 23:23:19]

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, 2016-08-09 02:35:25]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-08-09 02:37:54]

Description was changed from

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs. 

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items (http://crrev.com/2210873003)
 [3] Only add new devices, connected devices and devices that changed
     (http://crrev.com/2217573002)

BUG=508904
==========

to

==========
bluetooth: Replace old advertised uuids

Two changes:

 * Notify of DeviceChanged for any new advertisement received.
 * When a new Advertisement is received replace old cached UUIDs.

First of three patches to improve the devices that appear in the chooser:

 [1] This patch
 [2] Allow updates on chooser items (http://crrev.com/2210873003)
 [3] Only add new devices, connected devices and devices that changed
     (http://crrev.com/2217573002)

BUG=508904

Committed: https://crrev.com/8a06300cf9c86285d6f8f3b789549614fd19463e
Cr-Commit-Position: refs/heads/master@{#410541}
==========

[commit-bot: I haz the power, 2016-08-09 02:37:56]

Patchset 8 (id:??) landed as
https://crrev.com/8a06300cf9c86285d6f8f3b789549614fd19463e
Cr-Commit-Position: refs/heads/master@{#410541}