Repository navigation
[Bug]: Enforce configured maximumTxSeconds in the Android PTT watchdog #19
Description
Problem
The portal accepts ptt.maximumTxSeconds values from 1 to 120, but the Android service watchdog always uses a hard-coded 120 seconds. Values below 120 therefore do not change runtime behavior.
Accepted behavior
- Parse the active validated value into the managed radio connection/runtime state.
- Use that value for every service-owned managed PTT watchdog arm.
- Preserve the 120-second safe default and existing release-on-network-loss behavior.
- Add unit coverage for configured values, defaulting and bounds.
- Do not alter the dedicated-device exported-component policy in this issue.
Acceptance
- Android unit tests pass.
- Fresh FOSS debug/release assembly passes.
- Static tests prove a configured value below 120 changes the watchdog delay.
- Physical T56 PTT timing remains a later acceptance step when hardware is connected.
Activity
awatchar commentedon Aug 24, 2026
Implementation started on branch fix/lab-correctness-batch from main 655d892. Scope is Android config parsing, service watchdog application and JVM coverage. Physical T56 timing will remain explicitly pending until hardware is connected.
awatchar commentedon Aug 24, 2026
Implementation complete in the integration branch: validated ptt.maximumTxSeconds (1..120) now reaches the service watchdog, is captured per transmission, covers both hold-to-talk and toggle transitions, and a live policy change releases TX and requires a real key release. JVM policy/config tests pass as part of 117 app tests. Physical short-limit/default-120 timing acceptance remains open until the T56 is connected.
awatchar commentedon Aug 24, 2026
Implementation is ready in PR #26.
What changed:
ptt.maximumTxSeconds(1..120) now reaches the service-owned watchdogoncannot extend the active deadlineVerification: 121 app JVM tests + 11 Humla tests pass; debug/release assembly pass. Physical short-limit/default-120 timing remains open until a radio is attached.
awatchar commentedon Aug 24, 2026
PR #26 is merged and the production portal deployment is healthy. This issue remains open only for its explicitly documented hardware acceptance when a radio is attached.