Hoping my report could help Fitbit fix the issue, let me start another thread on Aria Air.
There are plenty of complaints on the data sync issue and apparent QA issue with Aria Air.
Given that most users complaining about the issues are non-technical users, I believe I can provide a bit more useful complaint.
On top of that, I believe the behavior I am seeing is rather odd, so there might be an added benefit.
When I step on the scale with the App's "weight" screen or "today" screen opened, it shows a new "Log Weight" screen. However, the value shown is incorrect: Whatever the previously logged value is shown. For example, if I enter an arbitrary value of 500kg, it shows that value. The scale shows a realistic value of 67kg in my case. The screen has an orange circular icon with a white checkmark ✔ .
Now, an interesting thing happens when I step off and step on to re-measure the weight. Then the number on the screen is updated to match the number on the scale. The orange icon is gone. and I can save the weight.
I guess the core of the issue is an asynchronous data race problem. Probably there are two threads:
- The first one initializes a data structure that is going to be reflected on the screen, sets the old value as the "default" value, then opens the screen.
- The second one waits for and receives some kind of message from the OS regarding the bluetooth connection, and writes the received data to the data structure that was set up by the first thread.
There is an obvious data race; the second thread might have finished too fast. This may mean either two things could happen:
- First, the value received is overwritten by the "default" value, thus is never shown on the screen. When it receives the data for the second time (because I stepped on the scale again), then hte new data is properly reflected.
- Second, on an even faster device (because my pixel 3 may be comparably slower than newer models), the second thread may receive data far more quickly and write to an uninitialized data. This could cause the thread to error out and die due to Segfault or Nullpointerexcemption or whatever (I am not familiar with Android app development. Just a CS PhD.), leading to "my app doesn't sync!" complaints.
I agree that this could be a difficult bug, since it would never reproduce on an Android simulator or on a certain device. It would also depend on a build optimization setting (optimized release build or debug build). It is highly phone-specific because it depends on the execution speed and response time of the OS and the BT hardware. More thorough QA testing on real devices could have revealed this bug, but I suspect it would be still difficult to solve.
My system environment:
Phone: Pixel 3, Andoid version 12, security update 2021/10/05, Play system update 2022/02/01.
Latest fitbit version as of 2022/03/19.
I also have a Fitbit Inspire HR but is currently unpaired from the phone and unlinked from the app to separate the issues. No other Fitbit or Bluetooth devices linked to the account nor the phone.
The scale is set to kg mode. The phone language is set to US English (because I am a Japanese user living in US, normally using a JP setting), wondering if the locale could affect some data field which makes this buggy program find an incorrectly named field. (This happened in a Delta Airline app, which required the phone to be set to US locale to work properly. US companies have a long of history of doing internationalization wrong.)
