bluetooth: android: Implement RetrieveGattConnectedDevicesWithFilter

bluetooth: android: Implement RetrieveGattConnectedDevicesWithFilter

Also moves BluetoothDeviceWrapper into its own file: http://crbug.com/424792

BUG=630581

[ortuno, 2016-11-14 03:49:27]

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

[commit-bot: I haz the power, 2016-11-14 03:49:40]

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-11-14 03:55:52]

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

[commit-bot: I haz the power, 2016-11-14 03:55:53]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[ortuno, 2016-11-28 02:43:04]

Description was changed from

==========
bluetooth: (WIP) RetrieveGattConnectedDevicesWithFilter

BUG=630581
==========

to

==========
bluetooth:android: Implement RetrieveGattConnectedDevicesWithFilter

Also moves BluetoothDeviceWrapper into its own file: http://crbug.com/424792

BUG=630581
==========

[ortuno, 2016-11-28 03:20:49]

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

[ortuno, 2016-11-28 03:20:50]

scheib: PTAL

[ortuno, 2016-11-28 03:20:56]

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

[commit-bot: I haz the power, 2016-11-28 03:21:07]

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-11-28 07:00:37]

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

[commit-bot: I haz the power, 2016-11-28 07:00:38]

Dry run: This issue passed the CQ dry run.

[scheib, 2016-11-28 18:20:06]

Description was changed from

==========
bluetooth:android: Implement RetrieveGattConnectedDevicesWithFilter

Also moves BluetoothDeviceWrapper into its own file: http://crbug.com/424792

BUG=630581
==========

to

==========
bluetooth: android: Implement RetrieveGattConnectedDevicesWithFilter

Also moves BluetoothDeviceWrapper into its own file: http://crbug.com/424792

BUG=630581
==========

[scheib, 2016-11-28 20:42:22]

https://codereview.chromium.org/2499913002/diff/80001/device/bluetooth/androi...
File
device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothDeviceWrapper.java
(right):

https://codereview.chromium.org/2499913002/diff/80001/device/bluetooth/androi...
device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothDeviceWrapper.java:21:
* BluetoothDeviceWrapper is in its own file because jni cannot direclty use the
nested class
Wrapper.java explains what the concept of a wrapper class is, maybe point more
directly to top of Wrappers.java for explanation of this class purpose.

When explaining why it's in its own file, cite http://crbug.com/505554 I can see
this being nice because you got tired of copy pasting the previous comments
explaining the use of 'Object' type, but does it fix anything more than that?

Probably we should explain at top of wrappers.java why there's this terribly
large file and everyhting isn't just split out: doing so would require a .h and
.cpp file for every split .java file that uses JNI. Or, maybe we should just
split out everything ;P.

https://codereview.chromium.org/2499913002/diff/80001/device/bluetooth/androi...
device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothDeviceWrapper.java:26:
@JNINamespace("device")
This class needs JNINamespace because other classes from that namespace are
using it? It doesn't seem to be called directly by JNI.

https://codereview.chromium.org/2499913002/diff/80001/device/bluetooth/androi...
device/bluetooth/android/java/src/org/chromium/device/bluetooth/BluetoothDeviceWrapper.java:28:
class BluetoothDeviceWrapper {
Can this still be "static class"?

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

https://codereview.chromium.org/2499913002/diff/80001/device/bluetooth/blueto...
device/bluetooth/bluetooth_adapter_unittest.cc:930: #if defined(OS_MACOSX)
RetrieveConnectedPeripheralServiceUUIDs is confusing to me, and I don't see why
Mac and Android need to differ in the mechanism used to validate that calls were
made all the way to the Mock OS components. Let's pick one of either returning
the set of UUIDs requested, or just counts of calls (as
manager_get_connected_devices_attempts_ does). Or, explain in code why these are
different.

https://codereview.chromium.org/2499913002/diff/80001/device/bluetooth/test/a...
File
device/bluetooth/test/android/java/src/org/chromium/device/bluetooth/Fakes.java
(right):

https://codereview.chromium.org/2499913002/diff/80001/device/bluetooth/test/a...
device/bluetooth/test/android/java/src/org/chromium/device/bluetooth/Fakes.java:93:
public void simulateConnectedLowEnergyDevice(int deviceType) {
// c++ enum BluetoothTest::ConnectedDeviceType