bluetooth: Replace old advertised uuids

device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm

Index: device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm
diff --git a/device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm b/device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm
index 77dafb03c8d62ac8ccb545054ed18f306e1442e3..07e6d364b049ff1b4f3ab3c165d9b6d954b24cea 100644
--- a/device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm
+++ b/device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm
@@ -64,7 +64,12 @@ void BluetoothLowEnergyDiscoveryManagerMac::TryStartDiscovery() {
   };
 
   VLOG(1) << "TryStartDiscovery scanForPeripheralsWithServices";
-  [central_manager_ scanForPeripheralsWithServices:services options:nil];
+  [central_manager_
+      scanForPeripheralsWithServices:services
+                             options:@{
+                               CBCentralManagerScanOptionAllowDuplicatesKey :

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

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 23:00:17]

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.

+                                   @YES
+                             }];
   pending_ = false;
 }