bluetooth: android: Initial BluetoothDeviceAndroid implementation.

device/bluetooth/bluetooth_adapter_unittest.cc

 // Copyright 2014 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.
 
 #include "base/bind.h"
 #include "base/memory/ref_counted.h"
 #include "base/run_loop.h"
 #include "device/bluetooth/bluetooth_adapter.h"
 #include "device/bluetooth/bluetooth_device.h"
 #include "device/bluetooth/bluetooth_discovery_session.h"
 #include "device/bluetooth/test/bluetooth_test.h"
+#include "device/bluetooth/test/test_bluetooth_adapter_observer.h"
 #include "testing/gtest/include/gtest/gtest.h"
 
 #if defined(OS_ANDROID)
 #include "device/bluetooth/test/bluetooth_test_android.h"
 #endif
 
 using device::BluetoothDevice;
 
 namespace device {
 
@@ skipping 417 matching lines @@
   EXPECT_EQ(adapter_->GetName(), "FakeBluetoothAdapter");
   EXPECT_TRUE(adapter_->IsPresent());
   EXPECT_TRUE(adapter_->IsPowered());
   EXPECT_FALSE(adapter_->IsDiscoverable());
   EXPECT_FALSE(adapter_->IsDiscovering());
 }
 #endif  // defined(OS_ANDROID)
 
 // TODO(scheib): Enable BluetoothTest fixture tests on all platforms.
 #if defined(OS_ANDROID)
+// Starts and Stops a discovery session.
 TEST_F(BluetoothTest, DiscoverySession) {
   InitWithFakeAdapter();
   EXPECT_FALSE(adapter_->IsDiscovering());
 
   adapter_->StartDiscoverySession(GetDiscoverySessionCallback(),
                                   GetErrorCallback());
   base::RunLoop().RunUntilIdle();
   EXPECT_EQ(1, callback_count_--);
   EXPECT_EQ(0, error_callback_count_);
   EXPECT_TRUE(adapter_->IsDiscovering());
   ASSERT_EQ((size_t)1, discovery_sessions_.size());
   EXPECT_TRUE(discovery_sessions_[0]->IsActive());
 
   discovery_sessions_[0]->Stop(GetCallback(), GetErrorCallback());
   base::RunLoop().RunUntilIdle();
   EXPECT_EQ(1, callback_count_--);
   EXPECT_EQ(0, error_callback_count_);
   EXPECT_FALSE(adapter_->IsDiscovering());
   EXPECT_FALSE(discovery_sessions_[0]->IsActive());
 }
 #endif  // defined(OS_ANDROID)
 
+#if defined(OS_ANDROID)
+// Discovers a device.
+TEST_F(BluetoothTest, DiscoverDevice) {
+  InitWithFakeAdapter();
+  TestBluetoothAdapterObserver observer(adapter_);
+
+  // Start discovery and find a device.
+  adapter_->StartDiscoverySession(GetDiscoverySessionCallback(),
+                                  GetErrorCallback());
+  base::RunLoop().RunUntilIdle();
+  DiscoverLowEnergyDevice(1);
+  base::RunLoop().RunUntilIdle();
+  EXPECT_EQ(1, observer.device_added_count());
+  BluetoothDevice* device = adapter_->GetDevice(observer.last_device_address());
+  EXPECT_TRUE(device);
+}
+#endif  // defined(OS_ANDROID)
+
+#if defined(OS_ANDROID)
+// Discovers the same device multiple times.
+TEST_F(BluetoothTest, DiscoverDeviceTwice) {
+  InitWithFakeAdapter();
+  TestBluetoothAdapterObserver observer(adapter_);
+
+  // Start discovery and find a device.
+  adapter_->StartDiscoverySession(GetDiscoverySessionCallback(),
+                                  GetErrorCallback());
+  base::RunLoop().RunUntilIdle();
+  DiscoverLowEnergyDevice(1);
+  base::RunLoop().RunUntilIdle();
+  EXPECT_EQ(1, observer.device_added_count());
+  BluetoothDevice* device = adapter_->GetDevice(observer.last_device_address());
+  EXPECT_TRUE(device);
+
+  // Find the same device again. This should not create a new device object.
+  observer.Reset();
+  DiscoverLowEnergyDevice(1);
+  base::RunLoop().RunUntilIdle();
+  EXPECT_EQ(0, observer.device_added_count());
+  EXPECT_EQ(0, observer.device_changed_count());
+  EXPECT_EQ(1u, adapter_->GetDevices().size());
+}
+#endif  // defined(OS_ANDROID)
+
+#if defined(OS_ANDROID)
+// Discovers a device, and then again with new Service UUIDs.
+TEST_F(BluetoothTest, DiscoverDeviceWithUpdatedUUIDs) {
+  InitWithFakeAdapter();
+  TestBluetoothAdapterObserver observer(adapter_);
+
+  // Start discovery and find a device.
+  adapter_->StartDiscoverySession(GetDiscoverySessionCallback(),
+                                  GetErrorCallback());
+  base::RunLoop().RunUntilIdle();
+  DiscoverLowEnergyDevice(1);
+  base::RunLoop().RunUntilIdle();
+  BluetoothDevice* device = observer.last_device();
+
+  // Check the initial UUIDs:
+  EXPECT_TRUE(ContainsValue(device->GetUUIDs(), BluetoothUUID("1800")));
+  EXPECT_FALSE(ContainsValue(device->GetUUIDs(), BluetoothUUID("1802")));
+
+  // Discover same device again with updated UUIDs:
+  observer.Reset();
+  DiscoverLowEnergyDevice(2);
+  base::RunLoop().RunUntilIdle();
+  EXPECT_EQ(0, observer.device_added_count());
+  EXPECT_EQ(1, observer.device_changed_count());
+  EXPECT_EQ(1u, adapter_->GetDevices().size());
+  EXPECT_EQ(device, observer.last_device());
+
+  // Expect new UUIDs:
+  EXPECT_FALSE(ContainsValue(device->GetUUIDs(), BluetoothUUID("1800")));
+  EXPECT_TRUE(ContainsValue(device->GetUUIDs(), BluetoothUUID("1802")));
+
+  // Discover same device again with empty UUIDs:
+  observer.Reset();
+  DiscoverLowEnergyDevice(3);
+  base::RunLoop().RunUntilIdle();
+  EXPECT_EQ(0, observer.device_added_count());
+  EXPECT_EQ(1, observer.device_changed_count());
+  EXPECT_EQ(1u, adapter_->GetDevices().size());
+  EXPECT_EQ(device, observer.last_device());
+
+  // Expect empty UUIDs:

[scheib, 2015/07/08 00:54:09]

armansito, confirm this is what you believe should happen if AD packets stop
including UUIDs.

[armansito, 2015/07/08 03:12:09]

On Chrome OS this will be populated with the complete list of UUIDs after we
perform service discovery over GATT, so GetUUIDs should also behave that way on
Android (so don't only return them based on scan results). I believe
http://developer.android.com/reference/android/bluetooth/BluetoothDevice.html...
does exactly that. So you should combine that list with mUuidsFromScan in
ChromeBluetoothDevice.java.

[scheib, 2015/07/08 05:09:10]

On Android, device.getUuids() will be empty unless we have explicitly requested
service discovery via fetchUuidsWithSdp() and waited for results. I see reports
on e.g. stack overflow that this will only work if a scan is stopped and then
SDP performed.

I'm perhaps surprised that ChromeOS would do a SDP before higher level code
connects to a device. Isn't SDP fairly expensive? 

Also, from a Web point of view, if a site starts a scan with requestDevice and
we collect only AD packets, aren't we able to divulge less information, e.g. is
a scan for AD packets passive only? If we perform SDP then a site can cause a
user's computer to connect with devices (granted, a user must have clicked on
the site).

[armansito, 2015/07/08 06:00:13]

SDP is a Bluetooth classic protocol, so it wouldn't be done in this case (though
I would expect getUuids() to contain services from GATT as well). Regardless of
LE or classic, upon connection all services will be discovered via SDP or GATT.
This is just done normally after you've scanned for devices and decided to
connect to one.

Both on Android and Chrome OS, GATT service discovery is always performed when
the ATT bearer is connected. Until that's done you get the UUIDs from AD or scan
response but once discovery is done the whole list is populated; that's about
it. So for example you do discovery ad you get one or two UUIDs from GetUUIDs().
Then you connect, now the list has 4-5 UUIDs.

[scheib, 2015/07/08 16:42:51]

OK, to be clear, upon a DiscoverySession we only expect to report UUIDS from AD
packets. We should not, just because of a DiscoverySession, connect and discover
services. (I see API for that in Android: connectGATT, discoverServices).

However, once connected GetUUIDs should report the merged list of UUIDs from AD
packets and discovered services.

For THIS patch, where we do not yet connect, should the UUIDs from AD packets be
cleared if a new AD packet is seen with different or empty UUIDs?

[Jeffrey Yasskin, 2015/07/08 17:19:39]

You're not really testing that situation here. You're faking the BLE device
above the OS layer, so you're directly controlling what UUIDs it returns. With
this sort of test, we can't test how the OS responds to a device interleaving
multiple different AD packets; we'd need a real radio for that.

[scheib, 2015/07/08 23:02:35]

I don't know what Android does for sure. Our test peripheral changes UUIDs, but
when it does it also gets a new address. However, this test should cover all
possible situations (changing, and changing to empty), even if Android isn't
that harsh to us. 

So, for the sake of determining what to do in the harshest case, what should we
do if Android updates to sending us an empty list? I think we discard the old AD
UUIDs, but speak up if you think otherwise.

[Jeffrey Yasskin, 2015/07/08 23:18:24]

I think that's right, until someone files a bug with a reason otherwise. 

+  EXPECT_EQ(0u, device->GetUUIDs().size());
+}
+#endif  // defined(OS_ANDROID)
+
+#if defined(OS_ANDROID)
+// Discovers multiple devices when addresses vary.
+TEST_F(BluetoothTest, DiscoverMultipleDevices) {
+  InitWithFakeAdapter();
+  TestBluetoothAdapterObserver observer(adapter_);
+
+  // Start discovery and find a device.
+  adapter_->StartDiscoverySession(GetDiscoverySessionCallback(),
+                                  GetErrorCallback());
+  base::RunLoop().RunUntilIdle();
+  DiscoverLowEnergyDevice(1);
+  DiscoverLowEnergyDevice(4);
+  base::RunLoop().RunUntilIdle();
+  EXPECT_EQ(2, observer.device_added_count());
+  EXPECT_EQ(2u, adapter_->GetDevices().size());
+}
+#endif  // defined(OS_ANDROID)
+
 }  // namespace device