New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 626913 link

Starred by 2 users

Issue metadata

Status: Archived
Owner: ----
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Chrome App Bluetooth API chrome.bluetoothSocket.connect(... uuid) connect to the wrong UUID service

Reported by chitting...@gmail.com, Jul 9 2016

Issue description

Chrome Version       : 51.0.2704.106 (Official Build) m (32-bit)

What steps will reproduce the problem?
(1) Implement a custom Bluetooth service on android with your own UUID. Start the service.
(2) Also install Pandora on Android, which has its own bluetooth services.
(3) Follow the chrome app bluetooth API tutorial (https://developer.chrome.com/apps/app_bluetooth) and implement a chrome app that connects to your Android bluetooth service with the same UUID and send/receive some simple messages.
(4) Pair the android device with the Windows computer.
(5) Try to send / receive some simple message between the Chrome App and the Bluetooth service on Android.


What is the expected result?
It should always connect to the bluetooth service you implemented on Android with the same UUID.

What happens instead?
It only works immediately after pairing. If the Android and Windows devices get disconnected and reconnected again (by moving out of range or restart the devices). There's a chance the Chrome App will connect to the wrong UUID service on the Android device. I've have it connected to the Pandora bluetooth service wrongly and have it play music automatically. (Apparently the Pandora service doesn't care who connects to it or what data it receives and just start playing music anyway.)

The problem can only be resolved by un-pairing then re-pairing the devices. Only then will it connect to the correct UUID service again.


Additional Info:
By looking at the deviceInfo returned from the getDevice API call:

{"address":"XX:XX:XX:XX:XX:XX",
"connectable":false,
"connected":true,
"connecting":false,
"deviceClass":5898764,
"name":"Nexus 6P",
"paired":true,
"type":"phone",
"uuids":["00001801-0000-1000-8000-00805f9b34fb",
"00001800-0000-1000-8000-00805f9b34fb",
"00001112-0000-1000-8000-00805f9b34fb",
"0000111f-0000-1000-8000-00805f9b34fb",
"0000110c-0000-1000-8000-00805f9b34fb",
"0000110a-0000-1000-8000-00805f9b34fb",
"0000110e-0000-1000-8000-00805f9b34fb",
"00001116-0000-1000-8000-00805f9b34fb",
"00001115-0000-1000-8000-00805f9b34fb",
"00001132-0000-1000-8000-00805f9b34fb",
"0000112d-0000-1000-8000-00805f9b34fb",
"0000112f-0000-1000-8000-00805f9b34fb",
"00001105-0000-1000-8000-00805f9b34fb",
"453994d5-d58b-96f9-6616-b37f586ba2ec",
"47cf661b-a8bd-47d9-d9c4-0f56c0584337",
"936da01f-9abd-4d9d-80c7-02af85c822a8"]}

It's clear that the ordering of the "uuids" fields are different when the device re-connect or re-pair with each other when the problem happens. https://www.diffchecker.com/endnpsrq

{"address":"XX:XX:XX:XX:XX:XX",
"connectable":false,
"connected":true,
"connecting":false,
"deviceClass":5898764,
"name":"Nexus 6P",
"paired":true,
"type":"phone",
"uuids":["00001801-0000-1000-8000-00805f9b34fb",
"00001800-0000-1000-8000-00805f9b34fb",
"00001112-0000-1000-8000-00805f9b34fb",
"0000111f-0000-1000-8000-00805f9b34fb",
"0000110c-0000-1000-8000-00805f9b34fb",
"0000110a-0000-1000-8000-00805f9b34fb",
"0000110e-0000-1000-8000-00805f9b34fb",
"00001116-0000-1000-8000-00805f9b34fb",
"00001115-0000-1000-8000-00805f9b34fb",
"00001132-0000-1000-8000-00805f9b34fb",
"0000112d-0000-1000-8000-00805f9b34fb",
"0000112f-0000-1000-8000-00805f9b34fb",
"00001105-0000-1000-8000-00805f9b34fb",
"47cf661b-a8bd-47d9-d9c4-0f56c0584337",  << swapped 
"453994d5-d58b-96f9-6616-b37f586ba2ec",  << swapped
"936da01f-9abd-4d9d-80c7-02af85c822a8"]}

I tried with both Nexus 6P and Nexus 5X, Windows 10 and Windows 8. The bug happens on all combinations.

Briefly tried Mac, so far cannot reproduce on it. Don't have Linux or ChromeOS.

 
Components: Blink>Bluetooth
Labels: Te-NeedsFurtherTriage

Comment 2 by ortuno@chromium.org, Jul 11 2016

Cc: mcchou@chromium.org
Components: -Blink>Bluetooth IO>Bluetooth
Owner: r...@chromium.org
Status: Untriaged (was: Unconfirmed)
Can you attach the chrome app you wrote in step (3)?
Attached a sample android app and chrome. To reproduce:
1. Install the Android App "BtTest"
1. Enable Bluetooth on Android
3. In BtTest, press both buttons: "start bluetooth service 0 and 1"
(Enable logcat D/BtAcceptThread, make sure you see log lines:
Waiting for incomming connection. Service 0
Waiting for incomming connection. Service 1)

4. Manually pair Android with Windows.

5. Install the Chrome app BtTestChrome
6. Run the Chrome App, and Look at console log.
7. Press "Connect and send message to Service 0 and 1" respectively.
8. Observe log lines:
(Received response: Service 0:Hello World
Received response: Service 1:Hello World)

Now to make the bug happens:
9. Stop bluetooth on Android (To kill the listening sockets)
10 Restart bluetooth on Android so that Windows see it again.
11. In BtTest Android app, press "Kill Bluetooth Service"
12. In BtTest Android app, press "Start Bluetooth Service 1 then 2" (in reverse order).
13. Repeat Step 7 and observe the log messages are reversed. Indicating they are connected to the wrong UUIDs.

Notes:
If you have Pandora running on the Android device, you may try to have the BtTest chrome app wrongly connect to it and trigger it to play music, by doing Step 9, 11 and 13 (skip 10, 12) (Can't reproduce 100% of the time though, My guess is maybe the bluetooth permission sometimes work correctly and block the connections, notice I've only granted 2 UUIDs in the chrome app)


BtTestChrome.zip
17.7 KB Download
BtTestAndroid.zip
508 KB Download

Comment 5 by ortuno@chromium.org, Jul 14 2016

I wonder if it's related to this:  http://crbug.com/392205 

Comment 6 by scheib@chromium.org, Jul 14 2016

Description: Show this description

Comment 7 by scheib@chromium.org, Jul 14 2016

Blocking: 507419
Status: Available (was: Untriaged)
Thank you for the high quality report & repro code.

Comment 8 by scheib@chromium.org, Jul 14 2016

Blocking: -507419
Status: Archived (was: Available)
Sorry, overlooked that this was chrome.bluetoothSocket vs chrome.bluetoothLowEnergy. I'm sorry set expectations that chrome.bluetoothSocket windows maintenance has been essentially non-existent and isn't staffed. Sorry, but don't expect this to be fixed.

Comment 9 by r...@chromium.org, Jul 14 2016

Owner: ----
well then you should update your document and deprecate your API, rather then wasting your user's time on this. no?
You are correct and I apologize.

Sign in to add a comment