Connect version 4.20 broke local http access?

Hello Stephen, 

according to my knowledge lots of the apps using local http communication are based on nanohttpd webserver just like the open sourced gimporter app: 
https://apps.garmin.com/en-US/apps/de11adc4-fdbb-40b5-86ac-7f93b47ea5bb
https://github.com/gimportexportdevs/gimporter

Uses cases are nicely visible here. Http is used both for sending JSON data and also for supported binary data (courses). I believe its commonly known how much are  requested apps allowing users to import content to their garmins directly from their phone. In this case all must be initiated on Garmin device by the user. Those JSON data should be able to be transferred also via phone messaging but then it will not work with the edge and other devices which doesn't support them unexpectedly from some time ago. 

In case of our Locus Map for Garmin app we spent lots of time to implement connectivity via phone messaging only to realise that it keeps failing for periodically sent data (https://forums.garmin.com/developer/connect-iq/i/bug-reports/failure_during_transfer) in real world. So now we are using hybrid comm via http in phone>android and Android SDK in other direction and also for wake up app from the phone. Via HTTP server in android we are transferring lots of datasets via JSON, FIT courses, and in near future image data. The architecture of the this connectivity is massively affected by abilities of CIQ.

Of course having remote http server on the internet is not the option for this kind of app as it is connecting to other API service in the phone and because it must maintain app to work even without access to internet. For now Locus Map for Android is supported only by watches which supports Android SDK and we are still trying to figure out how to port it to edge devices without loosing its features.

If there will be considered to add exception for local communication to GCM as used on other platforms, what time frame we can expect? Days or weeks? Thanks

In my apps case we are using (completely different) iOS and Android apps that each provide their own local web server that hosts data. The data is sourced from non-Garmin devices and uploaded to the cloud as well but the local web services are provided so watches and other devices can be used even when off of the internet.

Based on the feedback we've received, we are working with the GCM team to see if we can allow LocalHost requests via HTTP. It would be helpful if we could understand more specifically the use case. Are you using an android app server to do data manipulation? If you have any info that might help us, please let us know.

Hello, I am sorry for not being polite my previous post which was deleted by someone, but I still mean it. Current phone messaging via Android SDK is for several years critically broken (not to mention ditched from non-watch devices) and the only statements we periodically getting that there is some ticket for it deep in the backlog and something will take a look on it, while it seems that nobody touch this part for ages. I even didn't get response whether there is still somebody in the team who is able to maintain it.  I understand something is not being priority, but then update your docs finally and not force us to spend days to find out something is not working as it is promised!

This resulted that for several use cases we were able to rely only on http access to communicate from watch to phone. Not anymore as this also don't work now unexpectedly.. And please correct me if I am wrong but 2 and half year old post with some recommendation is not sufficient announcement fur such change.  

I don't believe we can expect soon some updated Android/iOS SDK allowing us to ditch web servers in those platforms for offline communication between phone and garmin devices. So that leave us to find usable solution to https server implementation (I was not successful yet) or hope you will give us option to keep using non encrypted communication. 

Can somebody please state what we can expect by recent change of creating new ticket about this topic (CA-61136)? Does it mean we can expect to some solution (and if yes when) or that this issue is only in consideration state for analysing some solution?

Thanks for the info - our users are waiting for them (as some of them currently downgrading their Garmin Connect).

They have never implemented that threat. HTTP was working quite fine with iOS as well as Android. Untill GCM 4.20 at least.