Repository navigation
[Bug]: Verify and harden service audio connection and wake-lock teardown #23
Description
Problem
Service teardown relies heavily on disconnect callbacks and does not have focused evidence that connection, audio resources and wake locks are always released when the Android service is stopped while the process remains alive.
Scope
- Add focused lifecycle tests around service destruction and disconnect ordering.
- Make teardown idempotent and release connection/audio/wake-lock resources where ownership requires it.
- Preserve normal reconnect behavior and the service-owned PTT safety path.
- Do not change the intended always-on auto-start watchdog policy.
Acceptance
- Repeated stop/destroy/disconnect ordering does not leak or double-release resources.
- PTT is released before teardown.
- Existing Humla/Mumla unit tests and FOSS builds pass.
- Physical process/audio verification remains a later T56 step.
Activity
awatchar commentedon Aug 24, 2026
Implementation and focused lifecycle analysis started on branch fix/lab-correctness-batch. The intended always-on process watchdog is out of scope; this issue covers idempotent connection/audio/wake-lock teardown only, with physical verification deferred.
awatchar commentedon Aug 24, 2026
Humla teardown hardening has been merged to the humla-minimum branch through PR #25 and the parent integration now points to that merge. Destroy state is volatile, deferred reconnect/late callbacks are gated, and connection handlers, audio input/output/encoder, SCO and wake locks use best-effort idempotent cleanup. Mumla also releases APRS, media/tone, notifications, receivers, proximity/screen wake locks even if another cleanup action throws. Humla 11/11 and app 117/117 tests pass; debug/unsigned-release assembly passes. Physical dumpsys/logcat audio/SCO/wakelock acceptance remains open until T56 attachment.
awatchar commentedon Aug 24, 2026
Implementation is ready in PR #26 (with the Humla teardown base already merged through PR #25).
Teardown is now best-effort and idempotent across connection, reconnect callbacks, audio input/output/encoder, SCO, notifications and wake locks. One cleanup failure cannot skip later resources. Destroy state blocks deferred reconnects and late callbacks.
A final review found and fixed an additional disconnect race: Mumla marks destruction before clearing app-owned fields; a late Humla disconnect still performs Humla cleanup but cannot touch cleared notifications/UI, while late sync/TALK is ignored.
Verification: 121 app tests + 11 Humla tests pass and APK assembly succeeds. Physical dumpsys/logcat audio/wakelock acceptance 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.