能否在Google Fit API的同一DataReadRequest中同时请求聚合与详细数据?
Great question—your updated DataReadRequest is syntactically valid, but there are a few common pitfalls that might be preventing you from getting the TYPE_LOCATION_SAMPLE data you want. Let's break this down:
Is your request supposed to work?
Yes, mixing aggregated data calls (like aggregate(DataType.TYPE_CALORIES_EXPENDED...)) with raw data reads (like read(DataType.TYPE_LOCATION_SAMPLE)) in the same request is fully supported by the Google Fit API. The switch from aggregating location to reading raw samples is a valid change, so the request itself should work if all other pieces are in place.
Common Reasons You're Not Getting Location Samples
Here are the most likely issues to check:
1. Missing or Incorrect Permissions
TYPE_LOCATION_SAMPLE requires specific permissions that are easy to overlook:
- Android Runtime Permissions: You need to request and be granted
ACCESS_FINE_LOCATION(orACCESS_COARSE_LOCATION) and, on Android 10+,ACTIVITY_RECOGNITION. Make sure you've declared these in yourAndroidManifest.xmland requested them at runtime before making the API call. - Google Fit OAuth Scopes: Your app's OAuth configuration must include the
https://www.googleapis.com/auth/fitness.location.readscope to read location data from Google Fit's servers.
2. Location Data Isn't Associated With a Session
You're using bucketBySession(1, TimeUnit.SECONDS) to group results by session. If your TYPE_LOCATION_SAMPLE data wasn't inserted as part of a Google Fit Session, it won't appear in any session-based buckets.
To test this, try a simplified request without session bucketing:
DataReadRequest testRequest = new DataReadRequest.Builder() .setTimeRange(startTime, endTime, TimeUnit.MILLISECONDS) .read(DataType.TYPE_LOCATION_SAMPLE) .enableServerQueries() .build();
If this returns data, the problem is that your location samples aren't tied to a session. You'll either need to associate them with a session when writing, or switch to bucketByTime instead of bucketBySession.
3. No Location Data Exists in the Time Range
Double-check that startTime and endTime correctly cover a period where you know location data was written to Google Fit. It's easy to make off-by-one errors with timestamps (e.g., using seconds instead of milliseconds). Print these values and convert them to human-readable dates to confirm they match the period you're targeting.
4. Server vs. Local Cache Discrepancy
While enableServerQueries() forces the request to pull data from Google's servers, it's possible that your location samples were only stored locally (and never synced to the cloud) or that the server hasn't processed the data yet. Try checking the Google Fit app directly to see if the location data appears there—if it doesn't, the data wasn't successfully synced.
Debugging Next Steps
- Run the simplified, non-bucketed request above to confirm if location data exists at all.
- Verify all runtime and OAuth permissions are correctly set up.
- Check if your location data was inserted with an associated session (if you intend to use
bucketBySession). - Confirm the time range in your request matches the period where data was recorded.
内容的提问来源于stack exchange,提问作者fdieval

