Acknowledged
CIQQA-4201

Allow HTTP Access on Android

Currently, access to HTTP servers (without encryption) is only possible when Garmin devices are paired with iOS devices. When paired with Android devices, HTTPS is enforced.

To my understanding, this is not an inherent limitation of Android itself, but rather a choice in the implementation of Garmin Connect Mobile on Android.

The apps I develop focus on home automation use cases, where the watch communicates with servers running inside the user's home network, either directly over the local network or through lightweight VPN solutions such as Tailscale. These servers often do not provide HTTPS with valid certificates. In some setups this can be solved using cloud-based reverse proxies, but in many cases users would need to configure their own reverse proxy and certificate management, which is often beyond their technical capabilities.

As a result, practical use of these apps is currently often limited to iOS users.

While I understand that this is a relatively niche use case, I believe it is still a valid one where requiring HTTPS does not necessarily provide additional security benefits, especially for local or VPN-only connections controlled entirely by the user.

Therefore, I would suggest reconsidering this limitation on Android and allowing HTTP access for Connect IQ applications, similar to the current behavior on iOS. From an Android perspective, this may be as simple as enabling cleartext traffic support (for example via the usesCleartextTraffic option or a network security configuration).

the-ninth
  • in reply to the-ninth

    Good point - my oversight. I guess the only option would be to bundle a proxy server in you companion app to front the other local services and use one of the below techniques to give it TLS.

  • in reply to the-ninth

    I was around when the https requirement came about.  And it was due to changes in Android OS for security if I recall.  This wasn't just a change made by Garmin that can be reversed.  As I understand you can still do what you want with iOS, and if it was due to Garmin, iOS would have the same restriction.

  • in reply to msyea

      

    Thanks, those are interesting services. Still, I do not think they really solve the underlying issue. As far as I understand, they allow obtaining certificates for the provided domain names, but you still need a server under your control that can actually use and serve those certificates. In my case, the server itself does not support that, and even if it did, obtaining and configuring certificates is probably still too involved for the average user.

    The ideal solution would be for vendors to provide secure cloud services for API access to home automation components. But even then, not everyone is comfortable exposing their systems through cloud services, and many users prefer to keep everything local.

    In any case, it is clear that there are possible workarounds. The main point of this suggestion, however, is that I believe Garmin should simply allow this type of traffic in the first place.

  •    have you looked at services like https://sslip.io/#related - if you have the local IP of the companion app or other service on the local net - you can use https://192-168-0-25.nip.io/... share the IP address via BT and then call directly from watch.

    This is a common pattern if you want to connect via HTTPS to a private IP without embedding the private TLS key or having CA issues. You can create a webservice that enables https://{customer-device-uuid}.myapp.com -> private IP address, with a free letsencrypt cert.

    Four issues:
    1. letsencrypt rate limits - 50 new per week
    2. rotating certs - currently 90 days but reducing
    3. DNS -> private IP address - is DNS rebinding... some security tools block it
    4. private IP probably changes regularly

    All surmountable if you wish to put in the effort - or just use https://traefik.io/ - which I cannot recommend as I haven't used it but pretty sure they offer the service.

  • in reply to the-ninth

    I was doing development back when the https requirements first came about.  I mentioned the bug reports from that time but there were also posts in the general forum, as this impacted a number of apps.  For most of mine I could just switch to https, but for a few, it wasn't possible and I ended up just removing those apps.

    Your best bet is probably to see if your services will work with https.  Even if you find some other way, it's likely to be too complex or support intensive for many users,