Repository navigation
Reconnect when Bluetooth comes back on - #213
Merged
Merged
Conversation
Turning Bluetooth off and on could leave a car disconnected for good. The drop scheduled a retry 5 s later; when it fired with Bluetooth still off, connectGatt() returned null, no callback ever came, and the link stayed CONNECTING, which every later retry and ensureConnected() skip. Only turning tracking off and on recovered it (owner's phone, 2026-10-15). A null connectGatt() now fails the attempt so the backoff carries on, and the tracking service listens for Bluetooth turning on and retries every car that is not connected at once, with a fresh backoff. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This comment has been minimized.
This comment has been minimized.
Keeps TeslaBleController under detekt's TooManyFunctions threshold. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This comment has been minimized.
This comment has been minimized.
The pill said Connecting only in the CONNECTING phase and fell back to Disconnected while services were discovered, so it flashed Disconnected just before the car connected while the status line read Connecting... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This reverts commit 534f54c.
5 of 13 tasks
Contributor
SnapshotsNo visual change in the snapshots at 4921138 (vs 534f54c). Full-screen emulator shots: Actions → Debug APK: still building in Android CI (GitHub sign-in needed) |
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
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.
Requested by R
Summary
Before: turning Bluetooth off and on could leave a car disconnected for good, until tracking was turned off and on. On the owner's phone (2026-10-15) the first toggle recovered in 5 s; the second, with Bluetooth off for 6 s, never retried. The 5 s retry fired while Bluetooth was still off,
connectGatt()returned no client and no callback ever came, so the link stayed CONNECTING, which every later retry andensureConnected()skip. (Logcat shows no connect attempt after the drop; the null return is inferred from that and the code path.)After: a
connectGatt()that returns null fails the attempt, so the backoff carries on, and the tracking service listens forBluetoothAdapter.ACTION_STATE_CHANGED: when Bluetooth turns on, every car that is not connected retries at once with a fresh backoff.Type
Testing
./gradlew :core:test(no core change)./gradlew :app:testDebugUnitTest./gradlew :app:lintDebugAlso ran
:app:assembleDebugandktlintCheck. detekt is left to CI (local JDK 25).Checklist
expected.txtregenerated, not hand-edited (n/a)SPDX-License-Identifier: AGPL-3.0-only(n/a: no new files)🤖 Generated with Claude Code