Fix WearOS deep-link screenshot capture getting stuck on startup screen

[c0d3rb4b4]

Motivation

• The WearOS screenshot workflow was producing only the initial "Starting…" screenshot for multiple deep links because repeated explicit activity launches could leave the app in a stale state between invocations.
• A lightweight change was needed to reliably navigate the app for each deep link without sweeping workflow refactors.

Description

• Added an open_deep_link helper that force-stops the app, then attempts an implicit BROWSABLE intent targeting the app package and falls back to an explicit MAIN_ACTIVITY launch if needed in .github/workflows/wearos-emulator-screenshots.yml.
• Replaced the previous direct am start -n call in the deep-link loop with open_deep_link to ensure a fresh app state before each capture while preserving the existing foreground check and screenshot logic.
• Kept existing behavior for time/geo overrides, filename/manifest handling, and fallbacks untouched.

Testing

• Ran automated workflow sanity checks which verified the new open_deep_link() function is present and the capture loop now calls open_deep_link "$url"; these assertions passed.
• Performed git diff --check and committed the updated workflow file successfully without introducing whitespace errors.
• No runtime CI screenshot run was included here; the change was intentionally minimal to make reproduction and CI validation straightforward (see commit and amended workflow for usage).

---

Codex Task

[Copilot]

Pull request overview

Updates the Wear OS emulator screenshot GitHub Actions workflow to avoid deep-link captures getting stuck on the startup screen by ensuring the app is restarted and deep links are opened more reliably between captures.

Changes:

• Added an open_deep_link() helper to force-stop the app and attempt an implicit BROWSABLE deep-link launch with a fallback to explicit activity launch.
• Updated the deep-link capture loop to call open_deep_link "$url" instead of directly calling adb shell am start -n ....

Comments suppressed due to low confidence (1)

.github/workflows/wearos-emulator-screenshots.yml:474

• am start doesn't accept a bare package name as a positional argument; "$BUNDLE_ID" at the end is likely interpreted as an intent URI and will cause this implicit start to always fail. Use -p "$BUNDLE_ID" (or remove the argument entirely if you truly want an unrestricted implicit intent) so the implicit deep link attempt can succeed as intended.

            if adb -s "$emulator_serial" shell am start -W -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d "$url" "$BUNDLE_ID" >/dev/null 2>&1 </dev/null; then
              return 0

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This function runs under set -euo pipefail. If the fallback adb ... am start on the last line fails, Bash may exit the entire step before open_deep_link can return a non-zero status to the caller (so the loop won't reach the ::warning::Failed to open deep link path). Consider guarding the final start with || return 1 (or temporarily disabling set -e within the function) so failures are handled via the caller's if open_deep_link ...; then ... else ... logic.

Suggested change

	adb -s "$emulator_serial" shell am start -W -a android.intent.action.VIEW -d "$url" -n "$BUNDLE_ID/$MAIN_ACTIVITY" >/dev/null 2>&1 </dev/null
	adb -s "$emulator_serial" shell am start -W -a android.intent.action.VIEW -d "$url" -n "$BUNDLE_ID/$MAIN_ACTIVITY" >/dev/null 2>&1 </dev/null || return 1