Android Phone Sensors Missing Data
...
Android may be more aggressively limiting phone sensor data collection
see:
| Note |
|---|
Phone sensors pluginAndroid data sampling rate:The way intervals are managed in Android is inherently imprecise, as Android tries to group several events together to reduce battery drainage. Quote from Android: Your alarm's first trigger will not be before the requested time, but it might not occur for almost a full interval after that time. In addition, while the overall period of the repeating alarm will be as requested, the time between any two successive firings of the alarm may vary. Sampling rates are therefore only guaranteed at the average aggregate level. These properties affect all pRMT streams that are scheduled instead of being event-driven. Examples of event-driven streams are the hardware sensors, whereas periodic sampling happens on methods like contact lists, call logs, bluetooth devices, or weather. |
RSD-13 Text Messages Contacts Status can be NULL
...
it is not allowed to determine if OUTGOING messages ids are contacts (as far as we are aware, seems to be an API limitation)
see: source code https://github.com/RADAR-base/radar-android-phone/blob/master/src/main/java/org/radarcns/phone/PhoneLogManager.java#L260-L285
...
Some cases where there is Steps and other data but no Heart Rate data, here are some things to consider:
- Have you checked with the user to find out if they have been wearing their device tightly on their wrist, syncing their device regularly, had any issues with their device which they have reported to Fitbit, etc?
- Have you called Get Devices to see what devices are paired with the user's account, and how regularly they sync them?
- Does the user have mobile track enabled on their account? Mobile Track treats the phone as a pedometer,. If they are not wearing their device, but tracking steps with Mobile Track, this would explain steps without heart rate.
- Call Get Activities Log List endpoint, https://dev.fitbit.com/build/reference/web-api/activity/#get-activity-logs-list, and look for recorded exercises during the period of no heart rate. If you see any recorded exercises, the logType element will let you know the source of the exercise (e.g. tracker, auto_detected, mobile, etc). The auto_detected exercises are from the tracker.
ANDROID USAGE DATA
...
The android_phone_usage_event data is sent by the passive app that does not know the categories of the apps and hence its empty.
This data is then processed and app categories are added from the playstore in the backend and output the data to android_phone_usage_event_output.
Both of them use the same schema.
The android_phone_usage_event_aggregated uses this android_phone_usage_event_output data as input and creates windowed phone usage events with duration of usage of each app.
There was a bug that caused the file name unknown_date.csv in android_phone_usage_event_aggregated data but it is fixed now so the files should be name by time now.
Also another point, the android_phone_usage_event_aggregated and android_phone_usage_event_output depends on streams application on the server which is stopped due to resource constraints on the backend. So this data may not be updated anymore. But you can easily calculate this data from the android_phone_usage_event and playstore HTML parsing.
As for the eventType it will only be "Foreground" or "Background" as stated in the schema doc. The others are added just in case if needed in the future.
For the user interaction these are as suggested by their names -