Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

"webview crash: webview has crashed" in logs

After rebooting the phone, the device and phone connect once.

After a few minutes, I'm getting the following error in logs: "webview crash: webview has crashed"

The logs stop there.
The app on device keeps trying to comunicate, but is getting no response.

 

Is this a bug in the device code, the companion code, or the android application code.

 

The issue can be reproduced.

Best Answer
0 Votes
4 REPLIES 4

This sounds serious. I think the webview is used for displaying an app's Settings page. It might also be used for other parts of the Fitbit mobile app. Could you be doing anything advenurous in companion/settings code that could break the settings JSX display? Any other info about what should have been displayed on the phone at the time could also help.

Peter McLennan
Gondwana Software
Best Answer
0 Votes

Thanks for your answer Gondwana.

The source of "my" (I'm only trying to make this code run on versa 3)  code can be found in https://github.com/sulkaharo/nsfitbit

As far as I can tell nothing should have been displayed in settings.

The situation is that a reboot has happened and then the device connects and asks for data.

After some time there is the crash.

Best Answer
0 Votes

The app definitely has a settings component...

 

...but I note that it may be using http (rather than https) in some circumstances. A recent change to the Fitbit app broke this for local URLs (see here); I don't know if it's been fixed yet. Make sure you're using the latest version of the Fitbit app regardless.

 

http would never work for non-local URLs (contrary to examples in the app), so make sure you're using https in such cases.

Peter McLennan
Gondwana Software
Best Answer
0 Votes

Hi! The only local URL the app ever accesses is http://127.0.0.1/ and any other URLs entered by users are rewritten to use https. The settings page only ever executes javascript to set values on initial load and then onChange events when user changes the values, so there should be nothing in the settings page that can crash unless user loads the page and even then the code should be safe. The reason Tzachi is looking into the app is, the app works reliably on Versa 2, but on Versa 3 and Sense, something goes wrong periodically and the data sync between the watch face and the app companion breaks. What's bizarre about this is the app code has been setup so the app logic is exactly the same across the old and new firmware builds, with only thing different being the UI layer components that need to differ across the SDK versions. When the data sync breaks, _sometimes_ restarting the app on the watch fixes the issue (implying the issue is in the watch), but sometimes the Fitbit app needs to be killed and restarted, implying the issue is with the companion. Another symptom here is, when the issue happens, _sometimes_ the watch face app reports the files used to sync the data using the File-transfer API have been unexpectedly wiped from the watch, which AFAIK should never happen ( check to see if data or settings files are empty triggers on https://github.com/sulkaharo/nsfitbit/blob/master/app/index.js#L276). For whatever reason this exact same code works well in Versa 2 and the file sync issue triggers extremely rarely (literally less than once / month for the users I've talked to) while I can see this on daily basis on the Sense, often multiple times / day.

Best Answer
0 Votes