fix(maestro): stop on-device screenrecord; raise android widget cap to 30m

The Android per-flow video recording left the on-device `screenrecord` running:
stop_recording only killed the local `adb shell` client, so the recorder kept
going until its --time-limit (180s) and `wait` blocked ~2.5 min PER FLOW. That
silently added ~15 min to multi-flow shards and pushed them past the 20-min cap
(mass "cancelled" widget shards). Fix: `adb shell pkill -INT screenrecord` to make
the recorder finalize the mp4 promptly, then a bounded client kill so we never
block on the time-limit again.

Also raise the android-widget-tests cap 20→30 min as a hard backstop. With the
recording bug fixed a healthy shard finishes far under this; hitting 30 now means
real app instability, not cap tightness.

Author: vadim-v

.github/workflows/NativePipeline.yml

@@ -624,13 +624,12 @@ jobs:
     # Run if widgets need testing (widgets_to_test is not empty) and project succeeds
     if: ${{ needs.scope.outputs.widgets_to_test != '[]' && always() && needs.project.result == 'success' && (needs.android-app.result == 'success' || needs.android-app.result == 'skipped') }}
     runs-on: ubuntu-26.04
-    # 20 min per widget shard. With the up-front smoke check (fast-fail on a broken build) and
-    # the trimmed Precondition waits (60s×2, was 240s×3), a healthy widget — even the largest
-    # (web-view: 9 flows) — finishes well under this; a broken/hung one no longer grinds to the
-    # old 60-min cap. Backstop only; the smoke check should catch broken builds in ~1 min.
-    # (Was 15: a few legit-but-slow shards were truncated at the cap; 20 gives headroom without
-    # re-opening the runaway-hang window.)
-    timeout-minutes: 20
+    # 30 min hard cap per widget shard. A healthy widget's flows run in ~30s each; the cap is a
+    # backstop for genuinely wedged shards. Bumped 20→30 after a run where shards were cancelled
+    # at 20 min — that was traced to a video-recording bug (the on-device screenrecord wasn't
+    # being stopped, adding ~2.5 min/flow); with that fixed 30 is comfortable headroom. If shards
+    # still hit 30, the cause is real app instability, not the cap — needs a different fix.
+    timeout-minutes: 30
     strategy:
       # 5 parallel Linux shards. Bounded by GitHub Free's 20 total concurrent-job cap (not the
       # macOS-5 cap that limits the iOS matrix), so there's headroom. iOS stays at 4 to keep a

maestro/helpers/helpers.sh

@@ -52,15 +52,24 @@ stop_recording() {
   [ "$RECORD_VIDEO" = "true" ] || return 0
   local keep="$1"
   [ -z "$REC_PID" ] && return 0
-  # SIGINT lets the recorder finalize the file (moov atom / flush); SIGKILL would corrupt it.
-  kill -INT "$REC_PID" 2>/dev/null || true
-  wait "$REC_PID" 2>/dev/null || true
   if [ "$PLATFORM" == "android" ]; then
-    sleep 2  # let screenrecord flush to /sdcard before pulling
+    # CRITICAL: stop the ON-DEVICE screenrecord, not just the local adb client. Killing only
+    # REC_PID (the `adb shell screenrecord` client) leaves the recorder running on the device
+    # until its --time-limit (180s), so `wait` would block ~2.5 min per flow and blow the job
+    # timeout. `pkill -INT` makes screenrecord finalize the mp4 (moov atom) promptly.
+    adb shell pkill -INT screenrecord >/dev/null 2>&1 || true
+    sleep 2  # let screenrecord write the trailer + flush to /sdcard
+    kill "$REC_PID" 2>/dev/null || true   # client should already be gone; ensure it, never block
+    wait "$REC_PID" 2>/dev/null || true
     if [ "$keep" == "keep" ]; then
       adb pull "$ANDROID_REC_DEVICE_PATH" "$REC_FILE" >/dev/null 2>&1 || true
     fi
     adb shell rm -f "$ANDROID_REC_DEVICE_PATH" >/dev/null 2>&1 || true
+  else
+    # iOS: SIGINT lets simctl recordVideo finalize the file (moov atom); SIGKILL would corrupt it.
+    # recordVideo has no time-limit, so the client exits promptly on the signal.
+    kill -INT "$REC_PID" 2>/dev/null || true
+    wait "$REC_PID" 2>/dev/null || true
   fi
   REC_PID=""
   if [ "$keep" != "keep" ]; then