02-13-2020 21:29
02-13-2020 21:29
Dear Android Fitbit App Team,
Looks like plain HTTP is not working again from a companion app running in Android Fitbit App starting with Android 9, which disables plain HTTP by default. See this post for details:
It breaks existing Fitbit apps that require plain HTTP to work. A fix seems to be simple and is described in the post above. You would simply need to add the following line to Fitbit App's manifest:
android:usesCleartextTraffic="true"
Can you please fix it?
Answered! Go to the Best Answer.
02-19-2020 09:04
02-19-2020 09:04
We managed to get specific local addresses added to resolve the initial issue, but we haven't been able to convince the security team that all local traffic could be unencrypted. You can use 127.0.0.1, not localhost.
I will post more info when I have it.
02-13-2020 21:48
02-13-2020 21:48
I've been struggling with this too. My http: (and ws:) stuff works with Android 5(!), but not 9. On Android 9, I get ERR_CLEARTEXT_NOT_PERMITTED.
02-14-2020 07:50
02-14-2020 07:50
Looks like it can be fixed easily by Fitbit App team. I hope, they'll follow soon
02-17-2020 12:28
02-17-2020 12:28
I'm a bit surprised that there hasn't been feedback from more people if localhost without https is failing for everyone (there was when it happened last time).
Is anybody able to get http working over fetch() or websocket from companion on Android 9 with current Fitbit app?
02-17-2020 20:49
02-17-2020 20:49
02-19-2020 09:04
02-19-2020 09:04
We managed to get specific local addresses added to resolve the initial issue, but we haven't been able to convince the security team that all local traffic could be unencrypted. You can use 127.0.0.1, not localhost.
I will post more info when I have it.
02-19-2020 09:39 - edited 02-19-2020 09:58
02-19-2020 09:39 - edited 02-19-2020 09:58
@JonFitbit, thanks for the quick answer. I'm not saying that "all" traffic needs to be in clear. It should be optional just like it used to be. In my particular case, I use message level encryption, so side channel attacks will be more difficult than in plain TLS case, which is just a transport layer that can be easily spoofed by any client talking TLS (assuming that it's not mutual TLS).
Besides, I do need to talk to a local host somehow since Fitbit doesn't have a protocol for devices to talk to Android apps.
Implementing TLS server in an Android app would not add any additional layers of security in my case, but it will add a lot of headache:
A lot of troubles and re-work with no obvious benefits for app users.
02-19-2020 22:23
02-19-2020 22:23
Actually changing localhost in URL to 127.0.0.1 has helped: the Fitbit watch can talk to an Android app again, so it solved my problem.
02-20-2020 00:23
02-20-2020 00:23
...and for me. I can't believe I didn't try that! I suspect I actually did, but in combination with something else that wasn't working at the time.