Acknowledged
CIQQA-4804

Device passcode lock terminates watch apps with an active ActivityRecording session (native activities are exempt)

Device: Forerunner 970
Software version: 18.32
SDK: 9.2.0
App type: watch-app (sideloaded), minApiLevel 3.2.0
Reproducible: every time

Description

With the watch passcode on (Settings > System > Passcode, shared with Garmin Pay), taking the watch off the wrist ends a Connect IQ watch app even while it's recording with ActivityRecording. Built-in activities keep running in the same situation. This makes it impossible to build a Connect IQ app that records while the watch is off the wrist, e.g. a sport where the watch is left on the beach or in a bag. Users can't be asked to turn off the passcode, because Garmin Pay requires it.

Steps

  1. Set a watch passcode.
  2. Start a watch app that calls ActivityRecording.createSession({:sport => Activity.SPORT_SURFING, ...}) and session.start().
  3. Take the watch off the wrist.

Actual

  • A blue lock icon appears at the top, then a red stop square, then the app exits.
  • AppBase.onStop() is called. Our app saves the session there, so a short activity syncs to Garmin Connect, ending at the moment the watch came off.
  • Starting a session while the watch is already off the wrist ends the same way, almost immediately.
  • It's a clean exit, not the error screen from CIQQA-4693. The FR265 passcode thread linked below describes the same lock-triggered onStop(). CIQQA-4693 may be the same lock seen in apps that don't save in onStop(), though its reporter says that error also occurs with passcode off.

Expected

Same as a built-in activity. Test: the built-in Kayak activity on the same watch with the same passcode shows no lock icon and keeps recording off-wrist.

Questions / requests

  1. Is terminating a recording Connect IQ app on passcode lock intended?
  2. Could an app with an active, started ActivityRecording session be treated like a native activity by the lock (not terminated, lock deferred until the session ends)?
  3. If not, could onStop() tell the app why it is closing (e.g. a lock reason), or could this behavior be documented?

Related

9479668