tools/gpx_replay.py: replay a GPX through the location pipeline #23

New issue

Closed

opened 2026-08-31 17:14:42 +02:00 by robert · 1 comment

robert commented

2026-08-31 17:14:42 +02:00

(Migrated from git.butzei.de)

Goal

Make the whole thing testable indoors and repeatably, which matters far more once navigation lands.

Acceptance criteria

Reads a GPX and emits positions at a configurable speed multiplier
Can drive the Android emulator via mock locations
Can drive the companion directly through a debug hook
Supports pausing, jumping to an offset and injecting a deliberate off-route excursion
Documented in docs/DEV.md

Files

tools/gpx_replay.py

## Goal Make the whole thing testable indoors and repeatably, which matters far more once navigation lands. ## Acceptance criteria - [ ] Reads a GPX and emits positions at a configurable speed multiplier - [ ] Can drive the Android emulator via mock locations - [ ] Can drive the companion directly through a debug hook - [ ] Supports pausing, jumping to an offset and injecting a deliberate off-route excursion - [ ] Documented in `docs/DEV.md` ## Files - `tools/gpx_replay.py`

robert referenced this issue

2026-09-03 19:36:37 +02:00

Team, process, pipeline design and the 2026-09-03 readiness review #74

robert referenced this issue from a commit

2026-09-04 00:34:35 +02:00

Define the four CI lanes: dev-artifact, fast, slow and tag (#67)

robert referenced this issue from a commit

2026-09-04 19:53:42 +02:00

Implement StopDetector and SpeedPipeline: one definition of stopped (#69)

robert referenced this issue

2026-09-04 19:54:11 +02:00

Auto-pause: one definition of stopped, in Phase 2 (#69) #100

robert referenced this issue

2026-09-04 19:55:09 +02:00

Auto-pause: one definition of stopped, in Phase 2 #69

robert referenced this issue

2026-09-04 20:08:08 +02:00

Speed pipeline: smoothing, stop clamping, distance, moving average (#17) #101

robert referenced this issue from a commit

2026-09-05 10:50:41 +02:00

Add tools/gpx_replay.py and the debug fix-injection hook (#23)

robert referenced this issue from a pull request that will close it,

2026-09-05 10:51:10 +02:00

tools/gpx_replay.py: replay a GPX through the location pipeline (#23) #105

robert closed this issue

2026-09-05 10:52:29 +02:00

robert referenced this issue from a commit

2026-09-05 10:52:30 +02:00

Merge pull request 'tools/gpx_replay.py: replay a GPX through the location pipeline (#23)' (#105) from tooling/gpx-replay into main

robert commented

2026-09-05 10:52:46 +02:00

Owner

Closed by PR #105 (merged). Correctly read the issue's actual acceptance criteria from the API rather than trusting the Python-file-path hint or an initial prediction \u2014 turned out to be about driving mock locations into a real emulator/device via a debug hook, not JVM-side algorithm verification, so building tools/gpx_replay.py literally (not a Kotlin harness) was the right call, explicitly justified in the PR.\n\nWhat shipped: a stdlib Python CLI (36 tests, cross-checked against the real ~119km fixture's established ground truth) with three sinks \u2014 print, adb emu geo fix (emulator), and a new debug-only broadcast path (DebugFixReceiver/DebugBridgeLocationSource) for injecting fixes into a real running ride on a real device. The broadcast receiver is registered RECEIVER_NOT_EXPORTED, gated on the real ApplicationInfo.FLAG_DEBUGGABLE platform flag (never true in a signed release build), fully additive alongside real GPS \u2014 zero surface added to production builds. Filled in the slow-lane/tag-lane CI placeholder jobs that were literally named after and hard-failing pending this issue.\n\nHonestly unverified (no adb device/emulator in this sandbox): the emulator and debug-broadcast sinks against a live target, and whether unprivileged adb shell am broadcast reaches a RECEIVER_NOT_EXPORTED receiver on this project's API levels \u2014 both flagged explicitly with a documented fallback (RECEIVER_EXPORTED, with Bastion's review called out as warranted first) if it doesn't work as assumed.\n\nVerified for real: gpx_replay.py's own 36 unit tests, :companion:location:test (14 new), :companion:core:test/:companion:pebble:test unaffected, :companion:assembleDebug clean, manual runs against every real fixture in the repo.

Closed by PR #105 (merged). Correctly read the issue's actual acceptance criteria from the API rather than trusting the Python-file-path hint or an initial prediction \u2014 turned out to be about driving mock locations into a real emulator/device via a debug hook, not JVM-side algorithm verification, so building `tools/gpx_replay.py` literally (not a Kotlin harness) was the right call, explicitly justified in the PR.\n\n**What shipped**: a stdlib Python CLI (36 tests, cross-checked against the real ~119km fixture's established ground truth) with three sinks \u2014 print, `adb emu geo fix` (emulator), and a new debug-only broadcast path (`DebugFixReceiver`/`DebugBridgeLocationSource`) for injecting fixes into a real running ride on a real device. The broadcast receiver is registered `RECEIVER_NOT_EXPORTED`, gated on the real `ApplicationInfo.FLAG_DEBUGGABLE` platform flag (never true in a signed release build), fully additive alongside real GPS \u2014 zero surface added to production builds. Filled in the slow-lane/tag-lane CI placeholder jobs that were literally named after and hard-failing pending this issue.\n\n**Honestly unverified** (no adb device/emulator in this sandbox): the emulator and debug-broadcast sinks against a live target, and whether unprivileged `adb shell am broadcast` reaches a RECEIVER_NOT_EXPORTED receiver on this project's API levels \u2014 both flagged explicitly with a documented fallback (RECEIVER_EXPORTED, with Bastion's review called out as warranted first) if it doesn't work as assumed.\n\nVerified for real: gpx_replay.py's own 36 unit tests, `:companion:location:test` (14 new), `:companion:core:test`/`:companion:pebble:test` unaffected, `:companion:assembleDebug` clean, manual runs against every real fixture in the repo.