Add OpenTracks support for Android - #1290
Merged
Merged
Conversation
Three artifacts from databases/database.db: - Tracks: each recording with its name, activity type, start and stop times, durations, distance, max speed and altitude range. - Trackpoints: the positions logged along a recording, with coordinates, altitude, accuracy, speed, bearing and the point type. KML output. - Markers: points placed deliberately on a running recording, with their coordinates and optional photo reference. KML output. Coordinates are stored as the degree value times 1E6 and are divided back (ContentProviderUtils.java lines 318-319 at tag v4.28.2); a stored -77034198 reads as -77.034198 on the tested device. Point type is decoded from TrackPoint.Type at the same commit, which distinguishes a segment start or end the person triggered from one the app decided on and from the device going idle. Each track stores its own UTC offset as total seconds, so the artifacts report both the UTC time and the wall clock the recording was made against rather than assuming a zone. The tested track recorded -14400, which is UTC-4. Verified on a multi-container tree: the two storage spellings collapse to one, a second Android user adds its own rows against a known delta (15 then 26 with a tenant holding 11), and a decoy package with an identical layout adds none. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Row counts from a real aleapp.py run against the emu_a15_oss_v6 corpus. The zero-row values are checked absences: the tables are present and empty in that image, confirmed against the source stores. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds OpenTracks (de.dennisguse.opentracks) support for Android. Three artifacts from databases/database.db, covering every table in the store:
Coordinates are stored as the degree value times 1E6 and divided back (ContentProviderUtils.java lines 318-319 at tag v4.28.2); a stored -77034198 reads as -77.034198. Point type is decoded from TrackPoint.Type at the same commit, which separates a segment start or end the person triggered from one the app decided on and from the device going idle.
Each track stores its own UTC offset in seconds, so both the UTC time and the wall clock the recording was made against are reported rather than a zone being assumed.
The app's no_backup/androidx.work.workdb is WorkManager job bookkeeping, not user data, and is not parsed.
Verified on a multi-container tree: the two storage spellings collapse to one, a second Android user adds its own rows against a known delta (15 trackpoints then 26 with a tenant holding 11), and a decoy package with an identical layout adds none. sample_data follows once a corpus capture postdates the recording.