Complete
over 5 years ago

Garmin Connect Mobile 4.22 for Android includes the changes to allow HTTP on 127.0.0.1.

Connect version 4.20 broke local http access?

Getting several reports of functionality no longer working, it looks like Android Garmin connect app version 4.20 may have broken web request to local host via urls like http://127.0.0.1:17580/sgv.json?count=3

Parents
  • 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).

Comment
  • 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).

Children
  • I can only agree to everything that Jan said.

    With this requirement the devices can only communicate to other services with internet connectivity. Weird for an outdoor device.

    Also strange that the SSL requirement is implemented with the wrong error code. Is that on purpose?