Undefined sourceBundleId when querying Google Fit activity

[JulianLaval]

When querying for the activity datatype on Google Fit, a number of events are returned with sourceBundleId as undefined, and often overlap with similarly timed events from com.google.android.gms.

Although I haven't yet been able to dive deeper, I'm assuming that that these are raw activity events generated by the phone. The documentation specifies that adding the filtered: true option to queries will filter out raw steps -- is it safe to assume that this will also filter out raw activity, or is a separate PR required to achieve this?

[ghost]

this is interesting.
The automatic activities are actually detected by the google play services, but the user is able to enter new ones from the Fit app (or another app linked to Fit). What kind of activities are returned with undefined sourceBundleID?

The "filtered" flag only applies to steps, not to activities. What do you mean with "raw activities" ?

[JulianLaval]

From what I can tell, these activities with no sourceBundleId all seem to be of type "walking", and of very short duration (a few seconds to a few minutes).

I suppose the question would be -- where are they coming from? My reasoning for calling them "raw activities" was based on the observation that these also seem to be aggregated / filtered / deduplicated into similar "walking" events with the sourceBundleId com.google.android.gms.

Any ideas?

[dariosalvi78]

do you have any other app installed that could be writing those?

It would be interesting to run an aggregated query and see if all of these are accumulated or if only the ones with sourceBundleID are considered.

In any case filtering these "raw" ones would be easy: just check if sourceBundleId is there, but I don't know how generalisable this approach would be.

[JulianLaval]

I'm afraid it's a user-submitted bug in that they were noticing many duplicates -- I'll try to see if I can get them to check the source apps that write to Google Fit!

Agreed that simply checking for the existence of sourceBundleId seems like a simple fix in our case, as there is no reason why it shouldn't be present (I would have thought it be mandatory?). You're right that this might not be generalisable though.

[dariosalvi78]

My guessing is that the aggregated queries should clean a bit of that up, but I don't know how applicable they are with your use case.