[Feature] Refactor and cleanup the connection and discovery behavior on both apps as the connection is now stable

[jaroslav-sazma]

First off — thanks for AirSync.

While reading through the source (main @ 3f3b494) I (AI) went looking for how the app behaves when the Mac is off or out of range for a long stretch, and I wanted to check a few observations with you before assuming I've misread something.

What I think I'm seeing

1. The retry interval settles at 10 s and stays there

In WebSocketUtil.tryStartAutoReconnect():

var backoffMs = 2000L
while (autoReconnectActive.get() && !isConnected()) {
    ...connect(...)
    delay(backoffMs)
    backoffMs = (backoffMs * 1.5).toLong().coerceAtMost(10_000L)
}

So the progression is 2 s → 3 → 4.5 → 6.75 → 10 → 10 → 10 … and the loop exits only on success, on manual disconnect, or when auto-reconnect is switched off. If the Mac stays off all day, that's roughly 8,600 attempts. I couldn't find a second-tier escalation anywhere (I grepped for WorkManager, AlarmManager and minute-scale constants) — is a longer ceiling something you'd already considered? I noticed autoReconnectAttempts and autoReconnectStartTime are assigned but never read, which made me wonder whether something along those lines was already planned.

2. The Wi-Fi lock is held across the whole loop

acquireWifiLock() is called once before the retry loop starts and WIFI_MODE_FULL_LOW_LATENCY is held until cancelAutoReconnect() runs. Would it make sense to acquire it around individual attempts instead, so the idle gaps aren't covered?

3. isLocalNetwork() checks the target address rather than reachability

if (ipAddress.startsWith("192.168.") || ipAddress.startsWith("10.") || ...

A stored Mac address always passes this check, so as far as I can tell the loop still calls connect() when the phone has no Wi-Fi association at all. Since the OkHttp client isn't bound to a specific Network, I think that means the attempt goes out over the default route — i.e. over cellular, where it can't succeed. I haven't verified this on a device, so I may well be wrong about what actually happens on the wire. Would a "do we currently have a network whose subnet matches a known address" pre-check be worth adding before the attempt?

The bit I found most interesting

AirSyncService.registerNetworkCallback() already consults BLE state:

if (isScanning && !BleGattServer.isAnyAuthenticated()) {
    DiscoveryOrchestrator.burstBroadcast(applicationContext)
    WebSocketUtil.requestAutoReconnect(applicationContext)
} else if (isScanning) {
    DiscoveryOrchestrator.burstBroadcast(applicationContext)
}

That uses BLE as a suppressor once a BLE link exists. What occurred to me is the inverse: BLE absence is also a reasonably strong hint that the Mac isn't nearby, and it's far cheaper to keep an advertisement running than to retry a TCP connection every 10 s.

I don't think "no BLE ⇒ stop entirely" would be right — BLE range is much shorter than Wi-Fi, a Mac two rooms away is reachable over the LAN but not over BLE, and Bluetooth may simply be off. But something graduated might fit:

• BLE peer visible → connect promptly, as today
• no BLE peer → keep retrying, but with a much longer ceiling (30 s → 2 min → 5 min?), and let discovery/wake-up handle the fast path

Since the Mac already sends a unicast wake-up via QuickConnectManager and bursts presence packets on launch/wake/network change, a slow Wi-Fi retry seems like it would still be enough of a safety net.

Why I'm asking

I'm only at my laptop for part of the day, so I got curious about what the Android side costs while there's simply no connection to be had. I'd also rather not have to flip auto-reconnect on and off by hand depending on where I happen to be.

To be clear, I haven't measured any of this — I was reading through the code out of interest rather than chasing an actual battery problem. If the cost of looking for a peer is small enough to go unnoticed in practice, please feel free to ignore all of this; I was mostly just curious.

Related: #131 (global on/off toggle) covers some of the same ground from the UX side, though this is more about what happens when the app is left in its default state.

Thanks again for the project.

[sameerasw]

Hi! Very appreciate the detailed feedback!

About the auto connect behavior entirely, it's been modified quite a lot along the line from our initial implementation. I think now we reached a good stable point but still for some reason i get reports of connection drops which I can not replicate. That's why I haven't really cleaned up the code fully. I should do at some point and reset the progress.

1. The retry interval settles at 10 s and stays there

   This one actually is kind of intended behavior as from my testing it seemed not to cause a noticeable amount of battery drain (avg use was below 1% over a full day). I initially had a stop point as I remember after 5 mins or so but then removed it because many users just wanted to never touch the phone to initiate the connection. But that being said, I should add some granular controls for this as a slider or so the user can then pick a timeout or rather keep it always.

2. The Wi-Fi lock is held across the whole loop

   This one I need to clear up, thanks for pointing out.

3. isLocalNetwork() checks the target address rather than reachability and keeping discovery while BLE is not reachable

   Actually this was not the initial behavior as AirSync was only made to be local network only. But then we added the support for Tailscale and other VPN support. That was the main reason the detection was expanded but I do need to make sure these extra/ extended behavior only happens if the "Expand networking" is enabled. But I do not currently have this implemented on mac app side so I should add the same expand networking to the mac app as well instead of expecting user to pick a specific network adapter manually.

I was going to take v4.1 fully as a network connection fix but I can not replicate any of the reported disconnections myself so instead I might just spend some time cleaning up the discovery and connection methods.

[jaroslav-sazma]

Thanks for the quick and thorough reply — that answers everything I was wondering about.

The "below 1% over a full day" figure is exactly the number I was missing, and it puts the whole thing to rest for my use case. Good to know the 10 s interval is deliberate rather than left over — the reasoning about users not wanting to touch the phone to start a connection makes complete sense, and a configurable timeout sounds like a nice middle ground if you ever get around to it.

Interesting that the isLocalNetwork() behaviour came out of Tailscale/VPN support — that hadn't occurred to me at all, and gating it behind "Expand networking" on both sides does sound like the right call.

I'll close this, since it was curiosity about how the thing works rather than a problem I was actually hitting. I'm about to start using AirSync properly, so if I do run into the disconnects you can't reproduce, I'll open a separate issue with logs and as much detail about the network setup as I can gather — in case another data point helps narrow it down.

Thanks again for taking the time to go through it.

[sameerasw]

Actually I am going to re-open this as you pointed out something I should take a look at and I am gonna forget if theres no issue for it 😁

This task will be for a entire connection implementation cleanup and proper refactor :)

[sameerasw]

Fixed and improvements will be in the next update