Repository navigation
[Bug]: Verify and harden service audio connection and wake-lock teardown #23
Description
Activity
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.
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.
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.
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
Acceptance