Android BLE API create a bond to BLE device unknownly on Chrome OS
Reported by
edwinmos...@gmail.com,
May 8 2018
|
||||||||||||||||||||||||||||||
Issue descriptionApparently I was trying to port over an Android Application with BLE API implementation to Chrome OS. The application works fine on an Android device and on Chrome OS after making some twerk in the code itself. What I want to bring up is the issue that the Chrome OS seem to be performing a bond to the BLE device when I didn't write any codes for it. This occurs when I am trying to reconnect to a BLE device after connecting to it and disconnecting from it once. I also did a check on my Android device to compare the print out through my Log output against the Chrome OS Log output that is running the application. That is when I realised that the UUID changed only for the Chrome OS and not on the Android device. The funny thing is that in Chrome OS bluetooth setting, I did not see any bonded device to my Chromebook whereas on my Android Studio. It is showing me the bonded device which is contradicting. The most interesting thing is when I tried to force a pairing with my BLE device and remove it again on Chrome OS. It reset everything back to normal with my BLE device advertising the desired UUID that I am filtering for. I thought found a way to fix so I tried removing my BLE device from the list of bonded device by creating a reflector of BluetoothDevice.removeBond() to perform the removal but it doesn't seem to do the trick. Hope dashed :| Anyway this is what I did to produce what I encounter: 1) Scan for BLE Devices 2) Connect to BLE device using BluetoothDevice.connectGatt() 3) Disconnect BLE device using BluetoothGatt.close() and Bluetooth.disconnect() 4) Re-scan for BLE devices(This is when I notice the change in UUID that is broadcasted) How I verify if my BLE device exist in the list of bonded devices: Through the use of BluetoothAdapter.getBondedDevices() API method to verify if my current device exist in the set of bond devices. Cheers, Edwin
,
May 8 2018
,
May 9 2018
I totally forgotten to add my Chromebook details: Google Chrome: 66.0.3359.137 Platform: 10452.74.0 ARC: 4734322 Flash: 29.0.0.140
,
May 9 2018
,
May 11 2018
As per comment#0 this issue seems to be specific to OS=Chrome and OS=Android. Hence adding appropriate OS label. Thanks!
,
May 25 2018
,
Jun 5 2018
edwinmoseslow@ -- Thanks for reporting this issue. Could you please share any sample application to reproduce this issue. Also, sharing the screencast/ video of the issue would help us in better understanding of the issue. Thanks!
,
Jun 6 2018
I was using this sample code, sample code: https://github.com/googlesamples/android-BluetoothLeGatt but I modified it to incorporate BluetoothLeScanner switch supports a higher API. ble scanner: https://developer.android.com/reference/android/bluetooth/le/BluetoothLeScanner In the screenshot you should able to see the, - device name - device address - service uuid - scan record details: https://developer.android.com/reference/android/bluetooth/le/ScanResult.html#getScanRecord() Somehow the service UUID changed after being connected once. The interesting thing is, when I tired to pair and unpair my ble device on chromebook via the bluetooth setting. It actually trigger my device to rollback to it's original state with the correct service uuid being return. There is a video that you may want to refer for more details. On the side note, it's working fine on an Android phone.
,
Jun 6 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 6 2018
,
Jun 6 2018
Sounds like a bug fixed in https://chromium-review.googlesource.com/c/chromium/src/+/1028574 Edwin, could you try M68? The current stable is M67, which unfortunately did not include my patch above. So you can flash the beta version. Beta should be M68 for now.
,
Jun 7 2018
I changed my chromebook channel to the developer channel in order to get M68 as the beta channel was on M67. I also tried out the same methods I used previously to scan for my ble device and it seems that the bonding issue seems to be resolved as my android application isn't logging any boned devices. With that being said, I still face an issue where I'm unable to reconnect to the same device as the serviceUuid seems to change after being connected and disconnect. You can refer to the attached screen shots. At first I thought of doing a pair and unpair to solve the issue which I did previously but I wasn't able to find my ble device on the chromebook bluetooth settings hence I did a reboot. Interestingly, after the reboot I was able to scan my ble device again. You can refer to the video if it help and it is taken after a reboot.
,
Jun 7 2018
I believe the reconnection fails on Android because the device is somehow removed from ChromeOS also, since you cannot find your device in your chromebook bluetooth setting. A question for Edwin: When you cannot reconnect to a device, could you try turning off bluetooth and turning it back on to enforce another round of device scanning (potentially multiple times with intervals in between), rather than rebooting? Let me know what happens if you do so. A question for Rahul or Miao: Is it expected that the device is removed from bluetooth setting once it's disconnected? You know, if the underlying OS doesn't know the device, Android has not chance to know that device either.
,
Jun 7 2018
,
Jun 7 2018
I tired enabling and disabling the bluetooth on the chromebook to enforce another round of scanning but that doesn't seem to work either. Anyways, I attach a video that may help you understand the issue better.
,
Jun 7 2018
Thanks. Now let's assume we are at the moment when you enable scanning in your app on both your chromebook and your phone after disconnection. While the app on your chromebook is still scanning, could you click on your profile icon -> go to bluetooth setting such that you can see different bluetooth devices in setting? By doing so, you enforce the OS to do active scanning for you. I *think* the root cause is that the OS is not doing active scanning in your previous video.
,
Jun 7 2018
I tried the method you suggested but same issue still stands. On the side note, I forgotten to mention that I'm filtering the scan to prevent scanning of other ble device via it's service uuid. If I remove that filter, I will be able to scan for the same device but what I'm trying to point out is that once the chromebook connect to the ble device and disconnect from it. It kind of affects the scanning of the same device as was shown in the screenshots where the service UUID becomes null/empty. On Android, with the same filter implemented it's still capable of receiving the information about the device's service uuid. This is shown in the attached video in comment#15. So I was wondering what really happened to the chromebook when it connect and disconnect from the ble device. And why is it unable to scan for the same ble device with the same service uuid filtering implemented after it's being connected once.
,
Jun 7 2018
So if I understand correctly, you have a scan filter based on a GATT service UUID. 1. When the filter is on, you cannot see the device in scan result on android but you can see the device in chromeos bluetooth setting, during reconnection. 2. When the filter is off, you can see see the device in scan result on both android and chromeos bluetooth setting, during reconnection. Correct me if I am wrong.
,
Jun 7 2018
Actually I can't see the the device on chromeos bluetooth setting when I updated to M68, not sure why though. With filter implementation: 1. I'm able to see the device in the scan result on the application itself. 2. After connecting and disconnecting from the device, I do a rescan and now I'm unable to see the device. Without filter implementation: 1. I'm able to see the device in the scan result on the application itself. 2. After connecting and disconnecting from the device, I do a rescan and I'm still able to see the device. The reason why I'm unable to see the device when filter is implemented is because the service uuid in the scan result is null(this is in the case where I had connected to the device once). Whereas without the filter, I'm able to see the device because I'm not searching for a service uuid instead I'm searching for all device that I'm able to detect. I hope this helps.
,
Jun 7 2018
> With filter implementation: 1. I'm able to see the device in the scan result on the application itself. 2. After connecting and disconnecting from the device, I do a rescan and now I'm unable to see the device. Without filter implementation: 1. I'm able to see the device in the scan result on the application itself. 2. After connecting and disconnecting from the device, I do a rescan and I'm still able to see the device. Thanks for the info. Would you mind providing the status of chrome os bluetooth setting in both cases? I want to narrow down the problem to a specific platform, either android or chromeos. I think we are pretty closed now.
,
Jun 7 2018
I'm not too sure what you meant but I assume that you want to know the status of the bluetooth setting for chrome os with and without filter? The filter is done within an Android application hence I would assume that it should not affect the bluetooth setting on chrome os but I maybe wrong. Anyways the chrome os bluetooth setting isn't able to detect the device ever since I updated to M68 but previously on M66, it was still capable of detecting the device.
,
Jun 7 2018
Ok. Say if you forget your android app for a moment, and simply do scanning on chromeos, according to your comment above, you cannot detect your device from chrome os bluetooth setting, no matter what (with or without disconnection), after M68. Am I correct?
,
Jun 7 2018
Yup, you're right.
,
Jun 7 2018
Cool. Could you provide a bit more details on the remote device you use, I mean, the device you want to connect to? A few things I would be interested in: 1) device type (watch, phone, headset, or whatever) 2) OS (android, ios) 3) How do you set up your GATT service on your device? I would see whether it's possible for me to get some identical settings on the remote device when I reproduce tmr.
,
Jun 7 2018
A few things I would be interested in: 1) device type: Arduino Leonardo with a bluetooth module 2) OS: Arduino 3) How do you set up your GATT service on your device? I attached a screenshot which I think that's what you are asking for?
,
Jun 7 2018
Btw I think I should also mention that my device is a BLE device, just in case.
,
Jun 11 2018
I take this one back. This sounds like an issue between ARC++ and chromium. Somehow the service discovery result is out of sync between bluez and arc++ bridge.
,
Jun 11 2018
I have to admit that I failed to reproduce this issue, I did not use an Arduino though. Instead, I had an android phone as my GATT server. And I am able to scan with advertising data filter "0x3333", which was the UUID on that GATT server, before and after disconnection. @Edwin, given that I failed to reproduce it, is it possible for you to share the exact code snippets or APK with me? I know sometimes my request is too much for other developers as they have NDA or something similar. Thanks!
,
Jun 12 2018
,
Jun 12 2018
Hmmmmmm quite interesting I don't actually know what's going on now... Could you provide the model of your chromebook? I would try to see whether this is a problem of specific hardware (1. on chrombook first, and 2. on the remote device later).
,
Jun 12 2018
This is the model of my chromebook: XE500C13-K01US Chromebook 3 11.6"
,
Jun 12 2018
I'm afraid that I have to mark this as not reproducible as this moment. I just got a Samsung Chromebook 3 this morning and I still could not reproduce your issue. Note that I am using an image from the canary channel, so you may want to try that out also.
,
Jun 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/69e6a7872f1de61abdaee62d873f12a4c8340e6e commit 69e6a7872f1de61abdaee62d873f12a4c8340e6e Author: Qiyu Hu <qiyuh@google.com> Date: Tue Jun 19 17:17:11 2018 arc: bluetooth: Fix a bug where we never send cached device as intended SendCached.*() never works as our imagination goes. Cached found devices are always ignored in SendDevices(). Also sends out paired devices in SendCachedDevicesFound(). A paired device can still have different UUIDs from last time we report to Android, which should get the latest UUID list as long as it's scanning. As a matter of fact, the secure client test needs to know the updated UUIDs on a paired device in order to figure out which one to connect to. This has an impact on crbug/853037 and crbug/841041 also, as devices are always paired before connected in BlueZ. BUG=b:78593133, chromium:853037 , chromium:841041 TEST=Confirm from logs that UUIDs are updated even for paired devices Change-Id: I6f1dae8be9bb1eb9b0d8cb5c2a146ec07d4ee099 Reviewed-on: https://chromium-review.googlesource.com/1105559 Commit-Queue: Qiyu Hu <qiyuh@google.com> Reviewed-by: Luis Hector Chavez <lhchavez@chromium.org> Cr-Commit-Position: refs/heads/master@{#568505} [modify] https://crrev.com/69e6a7872f1de61abdaee62d873f12a4c8340e6e/chrome/browser/chromeos/arc/bluetooth/arc_bluetooth_bridge.cc [modify] https://crrev.com/69e6a7872f1de61abdaee62d873f12a4c8340e6e/chrome/browser/chromeos/arc/bluetooth/arc_bluetooth_bridge.h
,
Jun 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/33c9e8163c4b728bbf0d88e088f20eb4988ba7ae commit 33c9e8163c4b728bbf0d88e088f20eb4988ba7ae Author: Qiyu Hu <qiyuh@google.com> Date: Tue Jun 19 21:38:47 2018 CHROMIUM: Merge eir_uuids into uuids When service uuids are only availabe in eir (extended inquery response), current implementation clears eir_uuids and refuses to update them once service is resolved. Thus, it's impossible to retrieve those service uuids once a device is connected, unless that device is removed from BlueZ cache. The effect of distinguishing uuids from eir_uuids is adding more code and cost to maintain two lists only. Time to simplify this piece. BUG= chromium:853037 , chromium:841041 TEST=Cannot reproduce the missing service uuid bug anymore Change-Id: Ia4659b055e24c4a572ab403fda375e460ad096e9 Reviewed-on: https://chromium-review.googlesource.com/1102670 Commit-Ready: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Dmitry Grinberg <dmitrygr@google.com> [modify] https://crrev.com/33c9e8163c4b728bbf0d88e088f20eb4988ba7ae/src/device.h [modify] https://crrev.com/33c9e8163c4b728bbf0d88e088f20eb4988ba7ae/src/adapter.c [modify] https://crrev.com/33c9e8163c4b728bbf0d88e088f20eb4988ba7ae/src/device.c
,
Jul 16
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/7459edbcbd0d2735827a96bb684260360f04562e commit 7459edbcbd0d2735827a96bb684260360f04562e Author: Qiyu Hu <qiyuh@google.com> Date: Mon Jul 16 21:43:25 2018 CHROMIUM: Merge eir_uuids into uuids When service uuids are only availabe in eir (extended inquery response), current implementation clears eir_uuids and refuses to update them once service is resolved. Thus, it's impossible to retrieve those service uuids once a device is connected, unless that device is removed from BlueZ cache. The effect of distinguishing uuids from eir_uuids is adding more code and cost to maintain two lists only. Time to simplify this piece. BUG= chromium:853037 , chromium:841041 TEST=Cannot reproduce the missing service uuid bug anymore Change-Id: Ia4659b055e24c4a572ab403fda375e460ad096e9 Reviewed-on: https://chromium-review.googlesource.com/1102670 Commit-Ready: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Dmitry Grinberg <dmitrygr@google.com> (cherry picked from commit 33c9e8163c4b728bbf0d88e088f20eb4988ba7ae) Reviewed-on: https://chromium-review.googlesource.com/1138981 Reviewed-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Luis Hector Chavez <lhchavez@chromium.org> Commit-Queue: Qiyu Hu <qiyuh@google.com> [modify] https://crrev.com/7459edbcbd0d2735827a96bb684260360f04562e/src/device.h [modify] https://crrev.com/7459edbcbd0d2735827a96bb684260360f04562e/src/adapter.c [modify] https://crrev.com/7459edbcbd0d2735827a96bb684260360f04562e/src/device.c
,
Jul 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eba14ad88e7fa55f1ae3d24209893f94738815d1 commit eba14ad88e7fa55f1ae3d24209893f94738815d1 Author: Miao-chen Chou <mcchou@chromium.org> Date: Mon Jul 16 22:30:45 2018 arc: bluetooth: Fix a bug where we never send cached device as intended SendCached.*() never works as our imagination goes. Cached found devices are always ignored in SendDevices(). Also sends out paired devices in SendCachedDevicesFound(). A paired device can still have different UUIDs from last time we report to Android, which should get the latest UUID list as long as it's scanning. As a matter of fact, the secure client test needs to know the updated UUIDs on a paired device in order to figure out which one to connect to. This has an impact on crbug/853037 and crbug/841041 also, as devices are always paired before connected in BlueZ. BUG=b:78593133, chromium:853037 , chromium:841041 TEST=Confirm from logs that UUIDs are updated even for paired devices TBR=qiyuh@google.com (cherry picked from commit 69e6a7872f1de61abdaee62d873f12a4c8340e6e) Change-Id: I6f1dae8be9bb1eb9b0d8cb5c2a146ec07d4ee099 Reviewed-on: https://chromium-review.googlesource.com/1105559 Commit-Queue: Qiyu Hu <qiyuh@google.com> Reviewed-by: Luis Hector Chavez <lhchavez@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#568505} Reviewed-on: https://chromium-review.googlesource.com/1138434 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Cr-Commit-Position: refs/branch-heads/3440@{#686} Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733} [modify] https://crrev.com/eba14ad88e7fa55f1ae3d24209893f94738815d1/chrome/browser/chromeos/arc/bluetooth/arc_bluetooth_bridge.cc [modify] https://crrev.com/eba14ad88e7fa55f1ae3d24209893f94738815d1/chrome/browser/chromeos/arc/bluetooth/arc_bluetooth_bridge.h
,
Jul 23
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/0d576c388c30023b21ef559c018621b75af73ace commit 0d576c388c30023b21ef559c018621b75af73ace Author: Qiyu Hu <qiyuh@google.com> Date: Mon Jul 23 20:24:54 2018 Revert "CHROMIUM: Merge eir_uuids into uuids" This reverts commit 7459edbcbd0d2735827a96bb684260360f04562e. Reason for revert: <INSERT REASONING HERE> Original change's description: > CHROMIUM: Merge eir_uuids into uuids > > When service uuids are only availabe in eir (extended inquery response), > current implementation clears eir_uuids and refuses to update them once > service is resolved. Thus, it's impossible to retrieve those service > uuids once a device is connected, unless that device is removed from > BlueZ cache. > > The effect of distinguishing uuids from eir_uuids is adding more code > and cost to maintain two lists only. Time to simplify this piece. > > BUG= chromium:853037 , chromium:841041 > TEST=Cannot reproduce the missing service uuid bug anymore > > Change-Id: Ia4659b055e24c4a572ab403fda375e460ad096e9 > Reviewed-on: https://chromium-review.googlesource.com/1102670 > Commit-Ready: Qiyu Hu <qiyuh@google.com> > Tested-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Dmitry Grinberg <dmitrygr@google.com> > (cherry picked from commit 33c9e8163c4b728bbf0d88e088f20eb4988ba7ae) > Reviewed-on: https://chromium-review.googlesource.com/1138981 > Reviewed-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Luis Hector Chavez <lhchavez@chromium.org> > Commit-Queue: Qiyu Hu <qiyuh@google.com> Bug: chromium:853037 , chromium:841041 Change-Id: Idad8354a5135e7a643e4b28d77ef6f1c4af24e8c Reviewed-on: https://chromium-review.googlesource.com/1147401 Reviewed-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> [modify] https://crrev.com/0d576c388c30023b21ef559c018621b75af73ace/src/device.h [modify] https://crrev.com/0d576c388c30023b21ef559c018621b75af73ace/src/adapter.c [modify] https://crrev.com/0d576c388c30023b21ef559c018621b75af73ace/src/device.c
,
Jul 23
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/e2c9f59ca00f96eb50296b4294f9590816559e34 commit e2c9f59ca00f96eb50296b4294f9590816559e34 Author: Qiyu Hu <qiyuh@google.com> Date: Mon Jul 23 20:37:27 2018 Revert "CHROMIUM: Merge eir_uuids into uuids" This reverts commit 7459edbcbd0d2735827a96bb684260360f04562e. Reason for revert: Breaking headset connection Original change's description: > CHROMIUM: Merge eir_uuids into uuids > > When service uuids are only availabe in eir (extended inquery response), > current implementation clears eir_uuids and refuses to update them once > service is resolved. Thus, it's impossible to retrieve those service > uuids once a device is connected, unless that device is removed from > BlueZ cache. > > The effect of distinguishing uuids from eir_uuids is adding more code > and cost to maintain two lists only. Time to simplify this piece. > > BUG= chromium:853037 , chromium:841041 > TEST=Cannot reproduce the missing service uuid bug anymore > > Change-Id: Ia4659b055e24c4a572ab403fda375e460ad096e9 > Reviewed-on: https://chromium-review.googlesource.com/1102670 > Commit-Ready: Qiyu Hu <qiyuh@google.com> > Tested-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Dmitry Grinberg <dmitrygr@google.com> > (cherry picked from commit 33c9e8163c4b728bbf0d88e088f20eb4988ba7ae) > Reviewed-on: https://chromium-review.googlesource.com/1138981 > Reviewed-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Luis Hector Chavez <lhchavez@chromium.org> > Commit-Queue: Qiyu Hu <qiyuh@google.com> Bug: chromium:853037 , chromium:841041 Change-Id: Idad8354a5135e7a643e4b28d77ef6f1c4af24e8c Reviewed-on: https://chromium-review.googlesource.com/1147401 Reviewed-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> (cherry picked from commit 0d576c388c30023b21ef559c018621b75af73ace) Reviewed-on: https://chromium-review.googlesource.com/1147402 [modify] https://crrev.com/e2c9f59ca00f96eb50296b4294f9590816559e34/src/device.h [modify] https://crrev.com/e2c9f59ca00f96eb50296b4294f9590816559e34/src/adapter.c [modify] https://crrev.com/e2c9f59ca00f96eb50296b4294f9590816559e34/src/device.c
,
Jul 24
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/7e13faff2b3bce0ceacf7c809746f073e43910e1 commit 7e13faff2b3bce0ceacf7c809746f073e43910e1 Author: Qiyu Hu <qiyuh@google.com> Date: Tue Jul 24 19:44:12 2018 Revert "CHROMIUM: Merge eir_uuids into uuids" This reverts commit 33c9e8163c4b728bbf0d88e088f20eb4988ba7ae. Reason for revert: Breaks service probing on devices putting service uuids in EIR Original change's description: > CHROMIUM: Merge eir_uuids into uuids > > When service uuids are only availabe in eir (extended inquery response), > current implementation clears eir_uuids and refuses to update them once > service is resolved. Thus, it's impossible to retrieve those service > uuids once a device is connected, unless that device is removed from > BlueZ cache. > > The effect of distinguishing uuids from eir_uuids is adding more code > and cost to maintain two lists only. Time to simplify this piece. > > BUG= chromium:853037 , chromium:841041 > TEST=Cannot reproduce the missing service uuid bug anymore > > Change-Id: Ia4659b055e24c4a572ab403fda375e460ad096e9 > Reviewed-on: https://chromium-review.googlesource.com/1102670 > Commit-Ready: Qiyu Hu <qiyuh@google.com> > Tested-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Dmitry Grinberg <dmitrygr@google.com> Bug: chromium:853037 , chromium:841041 Change-Id: Ifb49aacc3227248282fc5df771daeabeb3794c2b Reviewed-on: https://chromium-review.googlesource.com/1147600 Commit-Ready: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/7e13faff2b3bce0ceacf7c809746f073e43910e1/src/device.h [modify] https://crrev.com/7e13faff2b3bce0ceacf7c809746f073e43910e1/src/adapter.c [modify] https://crrev.com/7e13faff2b3bce0ceacf7c809746f073e43910e1/src/device.c
,
Jul 25
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/6f62d1461e02a6911bb3a687d9cf71cb6957f5c7 commit 6f62d1461e02a6911bb3a687d9cf71cb6957f5c7 Author: Qiyu Hu <qiyuh@google.com> Date: Wed Jul 25 07:14:55 2018 CHROMIUM: Merge eir_uuids into uuids This is a reland of crrev.com/c/1102670. crrev.com/c/1102670 merges eir_uuids into uuids. Due to the check of duplicate uuids during profile probing, service uuids in eir are not probed. As a result, those profiles become unavailable and cause disconnection after pairing. As profile probing involves only internal state lookup in BlueZ, we can fix the issue by removing the duplicate uuid check. The only cost is a few more CPU cycles. BUG= chromium:853037 , chromium:841041 TEST=Verify that the missing service UUID bug is no longer reproducible and no regression on connection is introduced Change-Id: Icef35a24f2ebf290fc56482cdfcc96debee54482 Reviewed-on: https://chromium-review.googlesource.com/1148901 Commit-Ready: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/6f62d1461e02a6911bb3a687d9cf71cb6957f5c7/src/device.h [modify] https://crrev.com/6f62d1461e02a6911bb3a687d9cf71cb6957f5c7/src/adapter.c [modify] https://crrev.com/6f62d1461e02a6911bb3a687d9cf71cb6957f5c7/src/device.c
,
Jul 26
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/a5ca7848eda56c60758273ffa13338937c1411d1 commit a5ca7848eda56c60758273ffa13338937c1411d1 Author: Qiyu Hu <qiyuh@google.com> Date: Thu Jul 26 17:47:58 2018 CHROMIUM: Merge eir_uuids into uuids This is a reland of crrev.com/c/1102670. crrev.com/c/1102670 merges eir_uuids into uuids. Due to the check of duplicate uuids during profile probing, service uuids in eir are not probed. As a result, those profiles become unavailable and cause disconnection after pairing. As profile probing involves only internal state lookup in BlueZ, we can fix the issue by removing the duplicate uuid check. The only cost is a few more CPU cycles. BUG= chromium:853037 , chromium:841041 TEST=Verify that the missing service UUID bug is no longer reproducible and no regression on connection is introduced Change-Id: Icef35a24f2ebf290fc56482cdfcc96debee54482 Reviewed-on: https://chromium-review.googlesource.com/1148901 Commit-Ready: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 6f62d1461e02a6911bb3a687d9cf71cb6957f5c7) Reviewed-on: https://chromium-review.googlesource.com/1150303 Commit-Queue: Qiyu Hu <qiyuh@google.com> [modify] https://crrev.com/a5ca7848eda56c60758273ffa13338937c1411d1/src/device.h [modify] https://crrev.com/a5ca7848eda56c60758273ffa13338937c1411d1/src/adapter.c [modify] https://crrev.com/a5ca7848eda56c60758273ffa13338937c1411d1/src/device.c
,
Jul 26
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/0487388899be7fb66c717083606ccfd4ab6429fb commit 0487388899be7fb66c717083606ccfd4ab6429fb Author: Qiyu Hu <qiyuh@google.com> Date: Thu Jul 26 20:59:50 2018 CHROMIUM: Merge eir_uuids into uuids This is a reland of crrev.com/c/1102670. crrev.com/c/1102670 merges eir_uuids into uuids. Due to the check of duplicate uuids during profile probing, service uuids in eir are not probed. As a result, those profiles become unavailable and cause disconnection after pairing. As profile probing involves only internal state lookup in BlueZ, we can fix the issue by removing the duplicate uuid check. The only cost is a few more CPU cycles. BUG= chromium:853037 , chromium:841041 TEST=Verify that the missing service UUID bug is no longer reproducible and no regression on connection is introduced Change-Id: Icef35a24f2ebf290fc56482cdfcc96debee54482 Reviewed-on: https://chromium-review.googlesource.com/1148901 Commit-Ready: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 6f62d1461e02a6911bb3a687d9cf71cb6957f5c7) Reviewed-on: https://chromium-review.googlesource.com/1150301 Commit-Queue: Qiyu Hu <qiyuh@google.com> [modify] https://crrev.com/0487388899be7fb66c717083606ccfd4ab6429fb/src/device.h [modify] https://crrev.com/0487388899be7fb66c717083606ccfd4ab6429fb/src/adapter.c [modify] https://crrev.com/0487388899be7fb66c717083606ccfd4ab6429fb/src/device.c
,
Aug 2
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/15b9c78bdac722010ffbfafc85aeb0d874f59cda commit 15b9c78bdac722010ffbfafc85aeb0d874f59cda Author: Bernie Thompson <bhthompson@chromium.org> Date: Thu Aug 02 02:21:34 2018 Revert "CHROMIUM: Merge eir_uuids into uuids" This reverts commit 6f62d1461e02a6911bb3a687d9cf71cb6957f5c7. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=870011 Original change's description: > CHROMIUM: Merge eir_uuids into uuids > > This is a reland of crrev.com/c/1102670. > > crrev.com/c/1102670 merges eir_uuids into uuids. Due to the check of > duplicate uuids during profile probing, service uuids in eir are not > probed. As a result, those profiles become unavailable and cause > disconnection after pairing. > > As profile probing involves only internal state lookup in BlueZ, we > can fix the issue by removing the duplicate uuid check. The only cost is > a few more CPU cycles. > > BUG= chromium:853037 , chromium:841041 > TEST=Verify that the missing service UUID bug is no longer reproducible > and no regression on connection is introduced > Change-Id: Icef35a24f2ebf290fc56482cdfcc96debee54482 > Reviewed-on: https://chromium-review.googlesource.com/1148901 > Commit-Ready: Qiyu Hu <qiyuh@google.com> > Tested-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Bug: chromium:853037 , chromium:841041 Change-Id: I9f67e553288e9e72304202e8cb9d43d7985cebd9 Reviewed-on: https://chromium-review.googlesource.com/1159833 Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> [modify] https://crrev.com/15b9c78bdac722010ffbfafc85aeb0d874f59cda/src/device.h [modify] https://crrev.com/15b9c78bdac722010ffbfafc85aeb0d874f59cda/src/adapter.c [modify] https://crrev.com/15b9c78bdac722010ffbfafc85aeb0d874f59cda/src/device.c
,
Aug 2
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/baaff790f7ca37ca08d7ad9786ba4b3d6905b07b commit baaff790f7ca37ca08d7ad9786ba4b3d6905b07b Author: Bernie Thompson <bhthompson@chromium.org> Date: Thu Aug 02 02:21:35 2018 Revert "CHROMIUM: Merge eir_uuids into uuids" This reverts commit 6f62d1461e02a6911bb3a687d9cf71cb6957f5c7. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=870011 Original change's description: > CHROMIUM: Merge eir_uuids into uuids > > This is a reland of crrev.com/c/1102670. > > crrev.com/c/1102670 merges eir_uuids into uuids. Due to the check of > duplicate uuids during profile probing, service uuids in eir are not > probed. As a result, those profiles become unavailable and cause > disconnection after pairing. > > As profile probing involves only internal state lookup in BlueZ, we > can fix the issue by removing the duplicate uuid check. The only cost is > a few more CPU cycles. > > BUG= chromium:853037 , chromium:841041 > TEST=Verify that the missing service UUID bug is no longer reproducible > and no regression on connection is introduced > Change-Id: Icef35a24f2ebf290fc56482cdfcc96debee54482 > Reviewed-on: https://chromium-review.googlesource.com/1148901 > Commit-Ready: Qiyu Hu <qiyuh@google.com> > Tested-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Bug: chromium:853037 , chromium:841041 Change-Id: I9f67e553288e9e72304202e8cb9d43d7985cebd9 Reviewed-on: https://chromium-review.googlesource.com/1159834 Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> [modify] https://crrev.com/baaff790f7ca37ca08d7ad9786ba4b3d6905b07b/src/device.h [modify] https://crrev.com/baaff790f7ca37ca08d7ad9786ba4b3d6905b07b/src/adapter.c [modify] https://crrev.com/baaff790f7ca37ca08d7ad9786ba4b3d6905b07b/src/device.c
,
Aug 2
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/2d9d500b283d0a20a0151c4c8fc826e637ad651c commit 2d9d500b283d0a20a0151c4c8fc826e637ad651c Author: Bernie Thompson <bhthompson@chromium.org> Date: Thu Aug 02 02:25:49 2018 Revert "CHROMIUM: Merge eir_uuids into uuids" This reverts commit 6f62d1461e02a6911bb3a687d9cf71cb6957f5c7. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=870011 Original change's description: > CHROMIUM: Merge eir_uuids into uuids > > This is a reland of crrev.com/c/1102670. > > crrev.com/c/1102670 merges eir_uuids into uuids. Due to the check of > duplicate uuids during profile probing, service uuids in eir are not > probed. As a result, those profiles become unavailable and cause > disconnection after pairing. > > As profile probing involves only internal state lookup in BlueZ, we > can fix the issue by removing the duplicate uuid check. The only cost is > a few more CPU cycles. > > BUG= chromium:853037 , chromium:841041 > TEST=Verify that the missing service UUID bug is no longer reproducible > and no regression on connection is introduced > Change-Id: Icef35a24f2ebf290fc56482cdfcc96debee54482 > Reviewed-on: https://chromium-review.googlesource.com/1148901 > Commit-Ready: Qiyu Hu <qiyuh@google.com> > Tested-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Bug: chromium:853037 , chromium:841041 Change-Id: I9f67e553288e9e72304202e8cb9d43d7985cebd9 Reviewed-on: https://chromium-review.googlesource.com/1159837 Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> [modify] https://crrev.com/2d9d500b283d0a20a0151c4c8fc826e637ad651c/src/device.h [modify] https://crrev.com/2d9d500b283d0a20a0151c4c8fc826e637ad651c/src/adapter.c [modify] https://crrev.com/2d9d500b283d0a20a0151c4c8fc826e637ad651c/src/device.c
,
Aug 2
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/533d756c4dd407b36027968067ad459399695f1b commit 533d756c4dd407b36027968067ad459399695f1b Author: Bernie Thompson <bhthompson@chromium.org> Date: Thu Aug 02 20:53:31 2018 Revert "CHROMIUM: Merge eir_uuids into uuids" This reverts commit 6f62d1461e02a6911bb3a687d9cf71cb6957f5c7. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=870011 Original change's description: > CHROMIUM: Merge eir_uuids into uuids > > This is a reland of crrev.com/c/1102670. > > crrev.com/c/1102670 merges eir_uuids into uuids. Due to the check of > duplicate uuids during profile probing, service uuids in eir are not > probed. As a result, those profiles become unavailable and cause > disconnection after pairing. > > As profile probing involves only internal state lookup in BlueZ, we > can fix the issue by removing the duplicate uuid check. The only cost is > a few more CPU cycles. > > BUG= chromium:853037 , chromium:841041 > TEST=Verify that the missing service UUID bug is no longer reproducible > and no regression on connection is introduced > Change-Id: Icef35a24f2ebf290fc56482cdfcc96debee54482 > Reviewed-on: https://chromium-review.googlesource.com/1148901 > Commit-Ready: Qiyu Hu <qiyuh@google.com> > Tested-by: Qiyu Hu <qiyuh@google.com> > Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Bug: chromium:853037 , chromium:841041 Change-Id: I9f67e553288e9e72304202e8cb9d43d7985cebd9 Reviewed-on: https://chromium-review.googlesource.com/1159832 Commit-Ready: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> Reviewed-by: Bernie Thompson <bhthompson@chromium.org> [modify] https://crrev.com/533d756c4dd407b36027968067ad459399695f1b/src/device.h [modify] https://crrev.com/533d756c4dd407b36027968067ad459399695f1b/src/adapter.c [modify] https://crrev.com/533d756c4dd407b36027968067ad459399695f1b/src/device.c
,
Aug 7
,
Aug 8
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/7e730a02ca9e04ef673a54cf7cf0b366bf4a64b3 commit 7e730a02ca9e04ef673a54cf7cf0b366bf4a64b3 Author: Qiyu Hu <qiyuh@google.com> Date: Wed Aug 08 01:09:06 2018 CHROMIUM: Change the semantic of UUIDs property in device Keep the list of eir_uuids in property "UUID". Avoid removing eir_uuids after service discovery. So the semantic of UUIDs property in device changes in the following way: 1. Without this patch, UUIDs contains eir uuids only before service discovery. After service discovery, UUIDs contains service UUIDs BlueZ discovers. 2. With this patch, UUIDs contains eir uuids only before service discovery. After service discovery, UUIDs continas service UUIDs and eir_uuids. BUG= chromium:853037 , chromium:841041 , chromium:870011 TEST=Verify that the missing service UUIDs bug is no longer reproducible Pair and connect w/ baiscally all peripherals @pbathini can provide Change-Id: Ifa2fcb4e074d8de10b6ed6902c36d451ebbea359 Reviewed-on: https://chromium-review.googlesource.com/1161543 Commit-Ready: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/7e730a02ca9e04ef673a54cf7cf0b366bf4a64b3/src/device.c [modify] https://crrev.com/7e730a02ca9e04ef673a54cf7cf0b366bf4a64b3/doc/device-api.txt
,
Sep 10
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/bluez/+/7950443b86cf0ef89a2473b62206fea68df8fae3 commit 7950443b86cf0ef89a2473b62206fea68df8fae3 Author: Qiyu Hu <qiyuh@google.com> Date: Mon Sep 10 23:09:19 2018 CHROMIUM: Change the semantic of UUIDs property in device Keep the list of eir_uuids in property "UUID". Avoid removing eir_uuids after service discovery. So the semantic of UUIDs property in device changes in the following way: 1. Without this patch, UUIDs contains eir uuids only before service discovery. After service discovery, UUIDs contains service UUIDs BlueZ discovers. 2. With this patch, UUIDs contains eir uuids only before service discovery. After service discovery, UUIDs continas service UUIDs and eir_uuids. BUG= chromium:853037 , chromium:841041 , chromium:870011 TEST=Verify that the missing service UUIDs bug is no longer reproducible Pair and connect w/ baiscally all peripherals @pbathini can provide Change-Id: Ifa2fcb4e074d8de10b6ed6902c36d451ebbea359 Reviewed-on: https://chromium-review.googlesource.com/1161543 Commit-Ready: Qiyu Hu <qiyuh@google.com> Tested-by: Qiyu Hu <qiyuh@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 7e730a02ca9e04ef673a54cf7cf0b366bf4a64b3) Reviewed-on: https://chromium-review.googlesource.com/1216748 Commit-Queue: Qiyu Hu <qiyuh@google.com> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org> [modify] https://crrev.com/7950443b86cf0ef89a2473b62206fea68df8fae3/src/device.c [modify] https://crrev.com/7950443b86cf0ef89a2473b62206fea68df8fae3/doc/device-api.txt |
||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||
Comment 1 by jrobbins@chromium.org
, May 8 2018