Hum Rahi

US-028.FE.1 — SOS Button Hold-to-Activate Frontend Implementation
────────────────────────────────────────────────────────────

Role
As a frontend developer on Ham Rahi,
I need to implement the SOS hold-to-activate button with its 5-second
countdown ring exactly as specified in the design handoff (US-028.DESIGN.1),
So that the citizen-facing app enforces deliberate activation, prevents
accidental SOS triggers, and communicates hold progress accurately to
the user.

User Story
As Priya,
I want to press and hold the SOS button and see a ring counting down
for 5 seconds before the emergency is activated,
So that I can confirm my intent, avoid false alarms, and clearly know
the moment help is being summoned.

In-Scope

• Rendering the SOS button in its idle state on the designated screen
• Detecting and maintaining a sustained touch/pointer-down event on
  the button surface
• Animating the circular countdown ring from 0 to 360 degrees over
  5 continuous seconds from the moment the hold is detected
• Triggering the activation callback (interface contract with US-029.BE.1)
  at the exact moment the 5-second hold is satisfied
• Resetting the ring animation to 0 and returning to idle state if the
  hold is released before 5 seconds
• Delivering haptic feedback at hold-start, each elapsed second, and
  activation as specified in the design handoff
• Handling simultaneous or multi-touch input gracefully (only the first
  registered touch on the SOS target should count; additional touches
  must not reset or double-advance the ring)
• Implementing the motion-reduced fallback as specified in the design
  handoff (no animation; alternate progress indicator)
• Ensuring the button and ring render correctly across all supported
  Android and iOS screen sizes and densities defined in the Ham Rahi
  device support matrix

Out-of-Scope

• SOS dispatch logic, WebRTC session creation, or server calls
  (US-029.BE.1 and downstream)
• Audio siren or alert playback
• Any UI shown after activation (post-SOS screens are separate stories)
• Backend session state management
• Police panel or operator-side UI

Acceptance Criteria

AC1 The SOS button is rendered on screen in the idle state with no
countdown ring visible; no hold event is registered unless the
user maintains continuous contact with the button surface.

AC2 On sustained press, the countdown ring begins animating
immediately from the 12 o'clock position and progresses clockwise
at a linear rate, completing a full circle in exactly 5 seconds
(±100 ms tolerance).

AC3 If the user releases the button at any point before 5 seconds,
the ring resets smoothly to zero and the button returns to idle
state; no activation event is emitted.

AC4 At exactly 5 seconds of continuous hold, the ring completes
and the frontend emits the SOS activation event to the interface
boundary shared with US-029.BE.1; the button enters the
activated visual state as per design spec.

AC5 Haptic feedback fires at: (a) hold start, (b) each completed
second (1 s, 2 s, 3 s, 4 s), and (c) activation at 5 s, using
the patterns defined in the design handoff.

AC6 On devices or OS settings where the user has enabled reduced
motion or accessibility animations, the animated ring is replaced
by the fallback indicator specified in US-028.DESIGN.1; the
hold-and-activate logic is unchanged.

AC7 Multi-touch input does not produce unintended behaviour: only
the initial touch on the SOS target is tracked; additional
simultaneous touches on the button area are ignored.

AC8 The button touch target is no smaller than 48 × 48 dp on any
supported screen configuration.

AC9 The component passes QA testing across a minimum of three
device profiles (small Android, large Android, iOS) without
visual regression or timing drift.

AC10 No activation event is emitted if the app moves to the background
mid-hold; on returning to the foreground, the ring resets to idle.

Definition of Done

• Component implemented and rendering correctly across the supported
  device matrix
• Hold-timing accuracy verified by QA (5 s ±100 ms)
• Early-release reset behaviour confirmed via test cases
• Haptic feedback confirmed on physical devices (not emulator only)
• Reduced-motion fallback verified on a device with that setting enabled
• Multi-touch edge case tested and confirmed harmless
• Background/foreground interrupt test passed
• No open P1 or P2 bugs against this component
• Code reviewed and merged