fix(calls): self-healing phone reconnect (tincan-c7b8g)#176
Merged
Conversation
…e modem re-arm, honest call readiness (tincan-c7b8g) Three gaps found in live testing after a phone drop overnight: - CallController gave up modem discovery permanently after a 30s fast backoff; now falls back to indefinite steady polling so a later reconnect self-heals without a daemon restart. - Daemon.Connect() only flipped internal state without touching BlueZ; now drives org.bluez Device1.Connect() (async — a sync call was found to block the daemon's single main loop for the whole connection attempt, verified live against a real device). - GetStatus() had no way to distinguish "SELinux module present" from "HFP link actually bound" — added a distinct call_link_ready capability reflecting CallController's live VoiceCallManager state, without repurposing the existing SELinux-scoped call_setup_ready. Filed tincan-cq5c7 (needs-tests) for coverage of the new decision paths.
quad341
added a commit
that referenced
this pull request
Jul 5, 2026
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
When the phone drops off tincand's Bluetooth connection — out of range, asleep overnight, whatever — call features currently stay broken until someone manually reconnects the device and restarts the daemon. This closes three related gaps so a reconnect self-heals:
Connect()on a paired-but-disconnected phone now actually drives the Bluetooth connection (Device1.Connect()), instead of only flipping tincand's internal state while the link itself stayed down.call_link_readyfield reflecting whether calling is actually possible right now (a live call service is bound). The existingcall_setup_readyis intentionally left alone — it tracks system-level readiness (e.g. the SELinux module), not per-connection state — so this is additive, not a redefinition.Review notes
reply_handler/error_handler), not synchronously. tincand runs a single event loop, and this call can block for the whole connection-attempt window — a synchronous version would freeze all daemon activity (messages, notifications, everything) until it returns or times out. If this ever regresses back to a blocking call, that's the daemon-wide freeze to watch for; it's easy to miss outside a live/integration run.call_link_readyfield in this change — natural follow-up, out of scope here.call_link_readywiring) are tracked separately and in progress; the existing full suite passes unmodified against this change.Test plan
test_dbus_client_live.py): 9/9 passed, no hangrelease-gates/self-healing-phone-reconnect-c7b8g-gate.md