Bluetooth handshake fix for Android after multiple disconnects

[h3lix1]

This is a hack to get bluetooth working on Android after multiple disconnects

The change..

• Added a short watchdog to the BLE phone API so the worker thread keeps any handshake activity on a tight leash: it now wakes immediately after draining the ToRadio queue or prefetching FromRadio data, returns RUN_SAME, and logs if the config handshake stalls for 3 seconds. It then disconnects bluetooth connection to kick the phone to do the right thing. (src/nimble/NimbleBluetooth.cpp:55-121).

• Ensured every disconnect resets the recent ToRadio packet cache so the next connection can replay the first packet without being dropped as a duplicate (src/mesh/PhoneAPI.cpp:101 plus supporting state helpers in src/mesh/PhoneAPI.h, src/mesh/PhoneAPI.cpp:131-795).

Problem Description...

• Android client just seems to never be interested in packets after disconnecting and re-connecting a few times
• DEBUG | 00:52:22 546 Client not yet interested in packets (state=2) in logs
• Android shows the bluetooth connection, but the client shows disconnected
• Connection gets into a stalemate

This breaks the stalemate by killing the bluetooth connection and letting it reconnect.

This is likely a client problem that we're masking in firmware. Maybe an Android problem. Maybe someone smarter than me can figure this out.

The second problem is having a packet cache that lives between connections that drops duplicates. This is a problem when communication to the device may require duplicate-looking packets between subsequent connections.

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other (please specify below)
    Xiao wiao esp32
    Heltec (Lora32) V4

[garthvh]

Seems like a client issue that needs to be corrected there.

[Copilot]

Pull Request Overview

This PR implements a bluetooth handshake fix for Android devices that get stuck after multiple disconnect/reconnect cycles. The fix adds a watchdog mechanism to detect stalled config handshakes and forcibly restart the BLE connection when timeouts occur.

Key changes:

• Added a 3-second timeout watchdog for config handshakes with automatic BLE disconnection
• Reset duplicate packet filtering on each new connection to allow proper handshake replay
• Modified thread scheduling to be more responsive during handshake periods

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/nimble/NimbleBluetooth.cpp	Implements watchdog timer logic and BLE disconnection handling for stalled handshakes
src/mesh/PhoneAPI.h	Adds timeout constants and handshake state tracking variables
src/mesh/PhoneAPI.cpp	Implements timeout detection logic and resets packet duplicate filtering on disconnect

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[h3lix1]

@garthvh
On the first issue, once the client issue is fixed (if it is a client issue) this can go away, or be left behind.

The second issue of dropping packets as duplicates on the bluetooth level is weird to me, but if we want to do that, we'll need to make sure the dedup doesn't happen on packets we want. This one is a firmware bug.

[thebentern]

The second issue of dropping packets as duplicates on the bluetooth level is weird to me, but if we want to do that, we'll need to make sure the dedup doesn't happen on packets we want. This one is a firmware bug.

That was to solve an issue with the iOS app DOSing the device with the same position packets after a number of disconnects (another hack). I'm not sure that's to blame for any of the recent Android reconnect issues though, since it's been in the firmware for quite a while. The original problem it solved may be gone now though, since the transports and concurrency model was totally refactored recently.

[h3lix1]

The second issue might not be specific to android. I should have split these two MRs as they're solving two different issues. These two seemed like a working combo to bring stability to the bluetooth stack after recent changes.

Alternatively we can remove the packet cache and try to find the issue in the Android client that is giving talk-to-the-hand vibes.

[DaneEvans]

That was to solve an issue with the iOS app DOSing the device with the same position packets after a number of disconnects (another hack).

Sounds like a client issue that they should fix there.