+BT engineers for ARC, can someone take a look?

+hennessywill

I've also confirmed that this bug exists on a Samsung Chromebook Pro running dev Android N

Android N will allow a connection, where Android M does not.  However, the communication is spotty.  Also disconnecting from a device inhibits further connections without app restart.

Another instance of this issue:

I have an Android app which interacts with custom BLE devices. This app works as expected on devices which have android version 4.4 to 6.0. Now I want to make this available on Chromebooks through the Google Playstore on Chromebooks(App Runtime for Chrome).

I installed this app on my Google Asus Flip Chromebook(Chrome OS version 55, ARC version 3617689) by sideloading the APK onto it. But it is not working as expected.

These are the steps I took:

Call a startLeScan() which gives the BluetoothDevice as a scanResult.
Call the connectGatt() method, and the device is connected and in the onConnectionStateChange() callback, get a handle to the BluetoothGatt.
Call the discoverServices.
After that, the onServicesDiscovered() callback is hit as expected with status = GATT_SUCCESS. However gatt.getServices returns an empty list when running on Chromebook. When running on Android device (API 19 to API23) I get BluetoothGattService handles to all the services supported by my BLE device.

from https://stackoverflow.com/questions/41972045/android-app-which-interacts-with-ble-devices-not-working-on-chromebook

Attached are the debug logs when the BLE connection is communicating as expected.

Deleted: debug-logs_20170612-151442.tgz 1.2 MB

debug-logs_20170612-151442.tgz 1.2 MB Download

Jason, please provide an update as we have a few devices we have to load for an upcoming conference we need this confirmation.

Also, restarting the bluetooth adapter from code doesn't appear to work properly.  Bluetooth stops but doesn't start again.  I find I have to kill the app, re-enable bluetooth, and start the app again.

For the record, here is the comment (05/30/2017) about this issue with M:
This is a "won't fix" issue for Android M on veyron_minnie for several reasons as follows. 
1) Android M has different underlying GATT callbacks defined which is not well-designed in the first place. This has been a pain point since we started.
2) Android N is at the corner and it has a better callbacks defined for GATT Database retrieval which resolves this issue by design.
Is there a chance for this potential partner to try another ARC++ device with N build? For instance, Samsung Chromebook Pro is equipped with N.

Re #10:

Hi Steven, can you help with enabling BT logging level (see the instructions below) before reproducing the restarting issue?

- Enable Bluetooth debug logging by adding "-d" flag in file
/etc/init/bluetooth.conf and reboot for the log level to take effect.
  To be more specific "-d" is added here:
/usr/libexec/bluetooth/bluetoothd ${BLUETOOTH_DAEMON_OPTION}
--nodetach "-d"
- Enable Chrome logging by adding flags in /etc/chrome_dev.conf
  --vmodule=*blue*=3 --log-level=0
- Reboot to make sure the flags are picked up by chrome and bluetoothd.

The restarting issue may be caused by the latency taken to toggle the power state of adapter. A restart op can be divided into stop and start op, where the later start op is invoked when the stop op has not yet finished, so the start op is ignored in that case. This assumption can be proven by adding delaying between stop and start ops.

Team - any update on this bug as its getting critical to resolve as several teachers have asked us to use chromebooks in the classroom. 

Hi.

I have the same issue with my Android BLE App in a Samsung Chromebook Plus in the stable channel. v59.0.3071.134 , ARC 4127355 and Android 6.0.1. No services are returned.
Trying in developer mode (v60 and Android 7) in the beta channel, services are returned but the App behaviour is not as expected. Random subscribes and reads in characteristics, unstable connection, etc.

Someone can give us any light if this problem is going to be fixed in the release of Android 7 for our Chromebooks ???

Thanks in advance.

Using the above referenced app on a Asus Chrombook Flip C100PA running the dev channel OS version 61.0.3163.38, the problem still exists.

Using the above testing app (BleScanner), connecting to one of our devices reports erroneous values:

# of services reported, 2, should be 3
# of times the connection operation is reported as successful, 5, should be 1
# of times the device is reported as connected, 5, should be 1

Attached is a screenshot of the BleScanner running on the chromebook. 

Deleted: Screenshot 2017-09-26 at 11.26.17 AM.png 110 KB

	Screenshot 2017-09-26 at 11.26.17 AM.png 110 KB View Download

The bug also occurs on Samsung Chromebook Pro dev channel v62.0.3202.28

Hi Steven,

Recently we have quite a few fixes for BLE on Chromebook, the fixes should be on dev channel of M63 next week. Please give it a try.

Hi Steven, can you help with enabling BT logging level (see the instructions below) before reproducing the restarting issue?

0) Enable Bluetooth debug logging by adding "-d" flag in file
/usr/bin/start_bluetoothd.sh and reboot for the log level to take effect.
  To be more specific "-d" should be added at this line:
/usr/libexec/bluetooth/bluetoothd ${BLUETOOTH_DAEMON_OPTION}
--nodetach "-d"

1) Enable Chrome logging by adding flags in /etc/chrome_dev.conf
  --vmodule=*blue*=3 --log-level=0

2) Reboot to make sure the flags are picked up by chrome and bluetoothd.

Please file a feedback report with mcchou@ mentioned in the issue description after producing the issue. Thanks.

mmchou, I have enabled bluetooth and chrome logging, rebooted, reproduced the issue and hit alt-shift-i and submitted a feedback report as requested.

I conducted some experiments.

On caroline-release/R66-10337.0.0
- I used adb to install app-debug.apk attached in C#0 to a chromebook, i.e., caroline.
- Let android enter developer mode and ran BleScanner.
  * It was weird that the app did not trigger scanning. I had to force discovery by tapping on the bluetooth icon in the system tray.
  * Once BleScanner found Dash (the robot), I tapped on Dash.
  * The chromebook connected to Dash and discovered services. Although the screendump showed 2 services were found by BleScanner, there were actually 3 services found when monitoring by a low-level btsnoop log:
    # UUID: Generic Access Profile (0x1800)
    # UUID: Generic Attribute Profile (0x1801)
    # UUID: Vendor specific (af237777-879d-6186-1f49-deca0e85d9c1)

A snippet of btsnoop log showed that 3 services were found.

< ACL Data TX: Handle 3585
  Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 3585
  Handle range: 0x0001-0x0007
  UUID: Generic Access Profile (0x1800)
  Handle range: 0x0008-0x000b
  UUID: Generic Attribute Profile (0x1801)
< ACL Data TX: Handle 3585
  Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 3585
  Handle range: 0x000c-0xffff
  UUID: Vendor specific (af237777-879d-6186-1f49-deca0e85d9c1)

The bottom line is that there were services found instead of 0 service. Hi Steven, could you conduct experiments with a newer image and see what you get? Thanks.

Deleted: Screenshot_eve_dash_20180312_1850.png 204 KB

	Screenshot_eve_dash_20180312_1850.png 204 KB View Download

Deleted: btsnoop_caroline_BleScanner_20180312.log 1.7 MB

btsnoop_caroline_BleScanner_20180312.log 1.7 MB View Download

Hi Steven or MakeWonder guys, could I have a copy of the user manual about the robot features and about how to operate the robot? In particular, I would like to know
- Is it possible to turn off the volume?
- What are the buttons used for?
- Does the device support pairing? What kind of security is provided?

josephsih,

  I am running 66.0.3356.0 which is the latest available on my Chromebook.  The BleScanner is getting 2 services reported by ARC, however the robot has three -- as your btsnoop log confirms.  Also, ARC is reporting 5 connection events when requesting a single connection to the robot via the android API.  

  I suspect the source of the bug is in the communication between the ARC layer and the underlying OS, since neither Android nor Chromebooks generally exhibit this issue on their own. 

  We have also noticed bugs around the Chromebook's bluetooth getting wedged, requiring toggling of the bluetooth in the system tray.  However, we have not found any correlation between the bluetooth adapter getting stuck and the issue of this ticket.

  There is no volume control for Dash, although the next version of our apps will have this feature.  The buttons are general purpose inputs which can be programmed by the user.  The device does not support pairing.  We employ a mix of security measures -- although none of which are triggered by the demonstration of this bug.

Steven, thanks for your feedback. There are several layers from bottom up to the app. It took time to clarify which layer is at fault. It looks to me that the problem lies in the bluetoothd daemon layer and so it is a generic issue that other peripherals would suffer from too. For some unknown reason, the bluetoothd daemon sometimes accidentally (or purposely) claimed some services such that they were not exported to upper layers. This would take a bit more time to dig deeper.

Since the root cause is found, I expect that this issue would not take too long to get solved.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/554c1ce1654a5cd8426024929cc9888c5f2b4979

commit 554c1ce1654a5cd8426024929cc9888c5f2b4979
Author: Joseph Hwang <josephsih@chromium.org>
Date: Wed Mar 21 05:21:41 2018

CHROMIUM: gap: enable the external flag

  This patch enables the external flag for gap so that
the gap service could be exported over D-Bus.

  Refer to how this was done for the deviceinfo profile
in a previous commit:

  Commit 0cef5a7996db8df569d04f2165f58e5aeed8441f
  deviceinfo: Enable external flag

BUG= chromium:722987 
TEST=There are two methods.
Method 1:
  - Connect to a peripheral.
  - Use dbus methods to query the org.bluez.GattService1
    interface in managed objects.
  - Confirm that the gap 0x1800 profile was exported like:
    GattService1 path: /org/bluez/hci0/dev_xx/service0001
    service_props: dbus.String(u'UUID'):
        dbus.String(u'00001800-0000-1000-8000-00805f9b34fb'
Method 2:
  - Install BleManager APK attached in C#0 of chromium:722987
    to ARC++ in a chromebook.
  - Launch the application.
  - Connect to a Dash robot. Confirm that there are 3 services
    instead of 2.

Change-Id: Icc473f9d6ef1ce4436fac2e49d91e7bb9a2d3e3a
Reviewed-on: https://chromium-review.googlesource.com/970063
Commit-Ready: Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Shyh-In Hwang <josephsih@chromium.org>
Reviewed-by: Dmitry Grinberg <dmitrygr@google.com>

[modify] https://crrev.com/554c1ce1654a5cd8426024929cc9888c5f2b4979/profiles/gap/gas.c

The patch landed in 10506.0.0

With the patch, chromebook could see all 3 services provided by Dash:
- Generic Access Profile (0x1800)
- Generic Attribute Profile (0x1801)
- Vendor specific (af237777-879d-6186-1f49-deca0e85d9c1)

When will this patch make it into the ChromeOS builds?

I just updated my Chromebook to the latest version available on the dev channel, 66.0.3359.31, and the bug persists.

The patch landed on "67.0.3376.0" which is M-67. The stable release would be June 5.

Let me ask whether we could get it merged to M-66.

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This request is too late for M-66, let's target M67 for it unless there is strong urgency to get it in m66

Yes we’d like to get in M-66 as we want to go to market with it soon.

The patch only involved a one-line change to enable a config option. It does not incur too much change. If test team could help verify the patch does not incur regressions, could we have it in for M-66? Thanks!

Please re-open this bug.  I have updated my Chromebook to M-67 and still the 2nd issue persists:

(2) onConnectionStateChange is called multiple times with the same parameters

See attached screenshot.  "Operation Success Count" and "Connection Message Count" should be 1, not more than 1.

Deleted: Screenshot 2018-03-29 at 11.27.08 AM.png 288 KB

	Screenshot 2018-03-29 at 11.27.08 AM.png 288 KB View Download

Hi Steven, could you explain what "Operation Success Count" and "Connection Message Count" mean? What do the counts indicate when they are larger than 1?

From the screenshot, 3 services were reported which looked correct.

If the incorrect counts was an issue, please open another issue and let's track it in the new one. Thanks!

I created the ticket to track this part of the issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=828904