Connect version 4.20 broke local http access?

I don't have any specific updates on this yet, but it's being looked at by the GCM team. I think there are a lot of strong use cases mentioned in this thread, and the suggestion that non-routable addresses should be available over HTTP seems entirely reasonable to me.

The earliest that this could be addressed is in the next GCM release, which should be later this month (GCM is on a monthly release cycle), but I can't say whether that's a realistic expectation. We're doing what we can to keep the GCM team aware of the impact to all of you and get decisions made. I apologize to everyone for the road block this has imposed. While jim_m_58 is correct that we advised switching to HTTPS in 2017, this clearly hasn't been strictly enforced and we apparently had a blind spot with regard to some of these use cases that require HTTP.

I'm optimistic that we'll have a solution, but it's unclear to me the time frame required to get one in place.

I don't have any specific updates on this yet, but it's being looked at by the GCM team. I think there are a lot of strong use cases mentioned in this thread, and the suggestion that non-routable addresses should be available over HTTP seems entirely reasonable to me.

The earliest that this could be addressed is in the next GCM release, which should be later this month (GCM is on a monthly release cycle), but I can't say whether that's a realistic expectation. We're doing what we can to keep the GCM team aware of the impact to all of you and get decisions made. I apologize to everyone for the road block this has imposed. While jim_m_58 is correct that we advised switching to HTTPS in 2017, this clearly hasn't been strictly enforced and we apparently had a blind spot with regard to some of these use cases that require HTTP.

I'm optimistic that we'll have a solution, but it's unclear to me the time frame required to get one in place.

You'll see a difference with GCM Android vs iOS.  You want to use https.

While jim_m_58 is correct that we advised switching to HTTPS in 2017, this clearly hasn't been strictly enforced and we apparently had a blind spot with regard to some of these use cases that require HTTP.

Is this correct now? I find some devices can make http requests and some cannot. Is http blocked by some devices or GCM

Since i had some tim today i did some tests

1. Using android studio i created an android app which did a plain HTTP request to a local webserver (in my case http://<ip>adress/script.php and show the output in a textview

2. test this code under SDK 26, 28 and 29

The outcome:

- when using a webview it worked under all SDK's

- when using a stringrequest Under SDK26: works perfectly, under SDK28 and 29 i immediately got a timeout error, just like currently happens in the ConnectIQ apps

So i started studying the official Android documentation (developer.android.com/.../security-config.html) which states that only the defualt changes, but apps who need plainhttp still can use it if they specify it in a network security xml file and i found out there is a very easy fix, which solves all uses cases above

1. Add  android:networkSecurityConfig="@xml/network_security_config" to the Application section in the manifest

2. Create a file res/xml/network_security_config with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

I retested and found out the timeout error is gone, my app could do plain HTTP again, also on SDK 28 and 29.

@Garmin developers: Please implement this fix!!!!!!!!!!!!!!!!!!!!!!!

Tx for the update

I agree with Jan - with this and other Connect regressions, as well as other CIQ networking limitations that prevent me from providing real functionality, its clear Garmin isn't serious about CIQ and I have adjusted the effort I put it to apps accordingly.