OpenTracks icon indicating copy to clipboard operation
OpenTracks copied to clipboard

Import/Export to Health Connect

Open thomassth opened this issue 2 years ago • 11 comments

Is your feature request related to a problem? Please describe.

It'd be very convenient to retrieve / record data to and from Google fit, Samsung health and other apps, potentially opening data retrieval from smartwatches and other proprietary devices, or incorporate new optional data types.

Depend on how the API is used, we may get to selectively export / import data

https://developer.android.com/guide/health-and-fitness/health-connect/get-started

thomassth avatar Apr 20 '23 04:04 thomassth

What is your problem that this would be solving?

dennisguse avatar Apr 20 '23 08:04 dennisguse

I mostly use Google fit for my health and fitness data gathering, but its route tracking capacity is subpar at best

I'd love to use opentrack instead, but currently importing and exporting data between the 2 isn't easy, and not doable on phones.

And since health connect is promo'd to be the single data source for Android health & fitness apps, potentially it'd also help ease people into this FOSS app from other sports tracking apps

thomassth avatar Apr 20 '23 14:04 thomassth

Is the GPX/KML import not sufficient?

dennisguse avatar Apr 24 '23 20:04 dennisguse

Current versions of Google fit lacks any kind of file export

thomassth avatar Apr 25 '23 00:04 thomassth

We had a similar question regarding upload to Google Fit: https://github.com/OpenTracksApp/OpenTracks/discussions/1152

You can manually export from Google Fit and then check if you can import this data into OpenTracks: https://support.google.com/fit/answer/3024190?hl=en

A direct integration requires including proprietary libraries which is a show stopper. Also it likely requires Internet access, which is another show stopper.

dennisguse avatar Apr 25 '23 06:04 dennisguse

I don't know where you're getting that showstopper conclusion, as health connect works on a device level and does not require internet permission.

thomassth avatar Apr 25 '23 16:04 thomassth

  1. Google Fit Android API requires PlayServices
  2. Google Fit Android API license is not obvious (likely cannot be included in F-Droid builds)
  3. Google Fit Android API is deprecated (EOL 2024): https://developers.google.com/fit/android
  4. Google Fit REST API requires Internet access

Same applies to successor Health Connect: https://developer.android.com/guide/health-and-fitness/health-connect/platform-overview/availability

Don't get me wrong: it would be doable (if somebody wants to put in the work), but is likely very unhealthy for OpenTracks. If you want to build this: create a separate application that fetches the data from Google Fit, converts it into a file formation supported by OpenTracks and trigger the import.

dennisguse avatar Apr 26 '23 05:04 dennisguse

@dennisguse as of Android 14, health connect is built into AOSP. As such it does not require play services and to my understanding the API license should be F-droid compatible.

https://developer.android.com/health-and-fitness/guides/health-connect/develop/get-started

Would you be open to reconsidering opening this issue or would you be open to another issue on health connect support, especially for exporting fitness data?

To give an example from a similar project: Gadgetbridge may or may not get support soon. https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/4481

aveao avatar May 09 '25 14:05 aveao

@aveao Sure. I don't know exactly the use case besides storing data in a central (on-device) database.

What would be your use case?

dennisguse avatar May 09 '25 14:05 dennisguse

I'm interested in the ability to access and view historic fitness tracking and vitals data (heartrate, sleep tracking, weight etc) from different sources in one place.

I must admit I do plan on using google fit for the other half of this equation, but adding support for this would also allow other apps to be able to provide the same functionality, provided someone puts in the work to write it. It may already exist, I should check.

Exporting data regularly to import it elsewhere is a viable option (which the app currently supports), but something automated with a standardized API would of course work better.

aveao avatar May 09 '25 14:05 aveao

Sounds reasonable.

My usual response: if somebody wants to implement this and it makes sense - go for it.

dennisguse avatar May 09 '25 16:05 dennisguse