App still crashing / stops running

[finger563]

The app currently runs for longer, but still crashes for unknown reason - potentially related to out of memory errors or something else. The interesting thing is that in the settings -> app info page it has the option to force stop the application which implies that it is still running. However the notification is no longer present and (as far as I can tell) it's no longer able to take or send data to the backend.

[finger563]

Will be testing over the next few days of travel now that we have :

• Exception catching in the database (should keep the app from crashing and give us better visibility into those errors)
• Better network / serialization performance by removing duplicate (de-)serialization of data from db to http
• went back to 1 minute data length for memory considerations

[finger563]

I have not seen the app crash while not in battery saver mode - I believe this is due to the timing changing while in battery saver; the 1 minute data collection timers then start firing much slower, meaning that more data is buffered in memory, more data is written to a single row, and more data is attempted to be sent to the server.

Possible solutions:

• reduce data collection frequency (possibly to SENSOR_DELAY_NORMAL)
• find a way to ensure timers / delayed messages always trigger when they're supposed to (possibly with Job Scheduler? (#18 )
• when we write the logs to file, ensure each record is no longer than some_max_log_length entries
• when we're adding data (e.g. in the sensor callback) write data and clear (call the _SaveData() function) if the number of sensor data is past some_max_log_length entries

Related: the battery life has gotten better, but is still not long enough for a full day's charge - it's under 8 hours right now - so regardless of other solutions, we may want to reduce data collection frequency anyway to conserve battery life.

[finger563]

I set the data collection frequency to SENSOR_DELAY_NORMAL which appears to be about 0.2 seconds and then set the watch into battery saver mode for approximately an hour. The app did not crash so that seems to be an improvement.

[finger563]

new test: set delay to exactly 0.1 seconds, start app, run in battery saver from 13:45 - 14:36 (which corresponded to loss of battery of 1% :) ) then see how the collected data looks. The app did not crash during the battery saver mode and shows that it has been running for 53 minutes now (in the notification)

edit 1: as expected this resulted in fewer than 50 records (7 to be precise for this watch):

Total number of records: 16
User identifiers:  ['test2', 'william']
Device UUIDs:  ['3b9d2af8cebfb9d8', '9fd1b5e937cf9793']
Number of records for  9fd1b5e937cf9793 :  7
Num Sensor Data:  40042 40042 40013 40042
Start time:  Fri, 24 May 2019 13:45:08
End time:    Fri, 24 May 2019 14:36:13

Edit 2: Time between each sensor reading (average = 0.0765 s): Example sensor data versus time:

[finger563]

Looks like we still need to increase the cursor window size some and probably need to implement the max log length check to break logs into smaller logs before writing to help ensure that we don't exceed the cursor window when querying

[finger563]

Based on the fact that my watch is still running the app but I've seen the max row length exception when trying to send one of the logs. Even though it's using 0.1 seconds as the sensor frequency the timer must have taken so long that it created too large a log

[finger563]

After that last change i've not seen the app crash or seen any of these exceptions. Now the exceptions we see (which don't crash the app) are related to sending the data - they arise from either intermittent network connectivity or the server returning error code 500 (so it's not accepting the data anymore). both of these are unrelated to the app so closing for now :)