For SDK 9.2.0 on a fēnix 7X-class device, suppose a watch app persists “paused,” then loses its ActivityRecording.Session reference on process termination. Native ownership/completion is unknown.
Related context only: CIQQA-4693 reports native Resume / Save / Discard choices after reboot. Does Garmin support that recovery/retirement flow when the original ActivityRecording.Session handle is lost, an unclosed native recording may still exist, local app metadata survives, and ownership cannot be proven? Please specify safe preconditions and target guarantees. This report does not establish that a fēnix 7X is in the same state or that Resume/Save/Discard is safe in this scenario.
The createSession documentation describes create-or-return behavior. Before designing any recovery action, could Garmin clarify:
- Can the app tell whether the returned Session is new or previously unclosed, including a stopped Session?
- Is there a stable, non-mutating native ID to persist and compare after relaunch, with an ownership or FIT-file binding?
- Is there an existing-only query/enumeration without createSession? Does timer OFF exclude unclosed native data?
- What supported preservation/save/discard/retirement procedure is safe when the original handle is lost and ownership is unproved? What establishes target scope and completion after failure/interruption?
- Can createSession used as a probe allocate, bind/adopt or otherwise affect native state?
- What happens across Storage clear, reinstall/update or a same-UUID replacement build?
- What checkpoint/recovery architecture handles native save succeeding while Storage confirmation fails?
Please specify device/firmware limits and authoritative guarantees. Current start time, profile ID, history or a false isRecording value should not be assumed to prove ownership/closure without a documented relationship.
No personal files or identifiers are needed. No recovery experiment is proposed.