Android 7.1, Bluetooth/GCM and network requests within Connect IQ

TL;DR - if your app accesses network resources using the new [FONT=Courier New]Communications.makeWebRequest()[/FONT] method, expect to receive support issues from some (or all) users running Android 7.1+.

My D2 Bravo watch has had issues with some widgets (built-in and Connect IQ) accessing network resources since I upgraded my phone to Android 7.1 recently. As part of the investigation I discovered that I could not replicate this problem with any of my widgets, which use the older [FONT=Courier New]Communications.makeJsonRequest()[/FONT] method. When I updated one of the widgets to use [FONT=Courier New]Communications.makeWebRequest()[/FONT] the widget immediately stopped working, returning an error of -2 (BLE_HOST_TIMEOUT). It's importantly to note that none of this is exposed in the simulator environment; this error is only seen on a real device when connected to a device via BLE and thus using GCM to access the Internet.

I also saw this same error with Garmin's own Tides app (a Connect IQ app, available in the Store), which I suspect is also using the newer method. The app reported it could not retrieve tide data until I connected my watch to a different Android device, one that was running Android 5.x.

This may or may not also be related to Bluetooth crashing within Android 7.1, as detailed in this thread.

I'm hoping to bring this up at the Connect IQ Summit next week since this seems like it might be an error related to several groups within Garmin.

Potentially related (or red herring) threads on the forums:

Cheers,
Douglas

gasteropod over 8 years ago

I too am experiencing problems with makeWebRequest(), although I am running Android 7.0 and I get a -300 timeout not -2.

I have a widget which has been working fine with http but after seeing the message on the Garmin blog about this being obsoleted I changed it to https. No problem, it should have been a 1 character change and my web site was already setup to run with http or https with a genuine signed certificate. But, it simply would not work with https giving an immediate -300 (NETWORK_REQUEST_TIMED_OUT) error. Of course it works fine in the simulator.

While troubleshooting I ended up building the sample WebRequest widget, loading this onto my watch but it worked. Very odd, so I switched this to use my web site (which happens to use the same certificate provider as the sample) and that worked too. But then I tried my widget again and that worked. Very odd. Anyway, I put it down to gremlins and moved on.

But, this weekend, after a GC mobile update it stopped working (which may or may not be coincidental), and now the WebRequest widget no longer works. I have restarted the watch, restarted the phone, and have done all the logical things but I can no longer get https working on my watch (Fenix 5X running firmware 2.90, CIQ 2.2.3, with GCM 3.17). Neither my widget, nor the sample WebRequest widget work any more always returning -300. It fails immediately though as if there is a problem detected rather than a timeout. If I change to an unresponsive web address, it times out but takes much longer, so although it reports -300 for a timeout, I do not believe it is timing out.

I am not sure if this is related to the problem in the original post or not, but thought it worth posting in this thread. Once I have spent a little more time on this I'll probably log this into the bug forum. But I'd be interested if others can get makeWebRequest() work with these same versions using https.

Brandon.ConnectIQ over 8 years ago

I'll get this reported and track down an Android 7.1 phone to test against. It sounds like this should be pretty straight-forward to reproduce, unless it's related to a specific phone.

dbrobert: Out of curiosity, did you get a chance to discuss this issue with anyone? The schedule was pretty packed, so there may not have been many opportunities to get into this during the summit. :)

UPDATE: It looks like you were able to talk to someone, because I've been copied on an email thread related to this issue. We're working with the device team to pin down the problem. I'll report back here with any updates.

dbrobert over 8 years ago

I'll get this reported and track down an Android 7.1 phone to test against. It sounds like this should be pretty straight-forward to reproduce, unless it's related to a specific phone.

dbrobert: Out of curiosity, did you get a chance to discuss this issue with anyone? The schedule was pretty packed, so there may not have been many opportunities to get into this during the summit. :)

UPDATE: It looks like you were able to talk to someone, because I've been copied on an email thread related to this issue. We're working with the device team to pin down the problem. I'll report back here with any updates.

Yes, the schedule was pretty packed, but in a good way. I casually mentioned the issue with Nick at the reception and with someone the following morning and then brought it up at one of the breakout sessions. I've since rolled my phone back to 6.0 but I'm going to try and track down a device that is supported by LineageOS since that would allow me to run the device through Android 6, Android 7.1.0, 7.1.1 and 7.1.2. One of the Garmin people I was talking to mentioned that they had heard from someone else that 7.1.0 and/or early 7.1.1 was fine but at some point in the transition to 7.1.2 this all starts happening.

I've also updated my original post with a list of forum threads which related to BLE and may or may not be related.

Coleman.Apps over 8 years ago

Hey,

I've been working on tracking this issue down. I was able to get a crash with tides app, but I'm not sure that it's related. I was seeing this crash on several different versions of android on 1.x devices only. Would you be willing to send us a project so we can test it out on our end? Please send it to [email][email protected][/email].

Thanks,
-Coleman