Repeatable disconnect issue on Android Client v0.3.2

[TheWanderingCrow]

I am having an issue with the stability of the VPN connection on v0.3.2 where the connection will fail during a network state change (Cellular -> WiFi -> Cellular).

So far I've had success repeating the issue by doing the following:

1. Starting on WiFi, connect via the android client, verify that peers are connected
2. Pull down the settings tray and disable WiFi, VPN connection disconnects
3. Reconnect via the android client, verify peers are connected
4. Enable WiFi and connect to an access point, VPN connection disconnects

I have also attempted to enable the "Always On VPN" setting within Android, this still causes the disconnect to happen but the client does attempt to automatically and is typically successful. This is only a work-around however, as I tested this on Proton VPN and Tailscale Android clients and they did not express this issue.

[adboelens]

I'm not completely sure if my disconnects happen during a network state change, but my connection to Netbird on Android 15 and 16 is very unstable. This is a big problem, because I need Netbird to connect to my Immich server and backup my pictures. Haven't seen an update of the client in a while and we are now running behind 0.64 as the last version on Android and 0.66 for the other clients.
I really hope Netbird will get this fixed soon. If it stays this unreliable, I might have to switch back to Tailscale.

[marcopaganini]

I'm also having frequent disconnects to the point of making it too unreliable for family use. Curiously, my current (old) solution using plain Wireguard is super stable and does not exhibit this behavior. I'll try to get it reproduced and report here.

[Meodoc]

Can only second this, even with the "Always On VPN" setting, the connection drops consistently after a few network changes (which I go through a lot on a daily basis). I really hope this will get fixed soon, other apps like Tailscale or WireGuard handle this very well, so it has to be possible.

[marcopaganini]

This is most probably silly (AI... sigh), but... According to devin.ai's look at the code, here are some possibilities:

Bug 1 (Most Likely): onLost silently fails due to null capabilities
NetworkChangeDetector.java:23-34

In onLost, checkNetworkCapabilities calls connectivityManager.getNetworkCapabilities(network) for the already-lost network. Android frequently returns null here because the network is already gone by the time the callback executes. When that happens, checkNetworkCapabilities returns early at line 25, never calling onNetworkLost() on the listener.

This means ConcreteNetworkAvailabilityListener.availableNetworkTypes never removes the lost network type, leaving stale state. Subsequent transitions then fail the filter conditions and no reconnect is triggered.

Example scenario — WiFi drops, mobile takes over:

WiFi connected → availableNetworkTypes = {WIFI: true}

WiFi lost → onLost fires → getNetworkCapabilities(lostNetwork) returns null → early return, state not updated

availableNetworkTypes still has {WIFI: true} (stale!)

Mobile becomes available → onNetworkAvailable(MOBILE) → checks !isWifiAvailable → false (stale!) → no notification

Engine never restarts

Bug 2: ConcreteNetworkAvailabilityListener only triggers on WiFi↔Mobile toggles
ConcreteNetworkAvailabilityListener.java:14-38

The filter logic is very narrow:

onNetworkAvailable only notifies when WiFi becomes newly available (line 22). Mobile becoming available never triggers a reconnect.

onNetworkLost only notifies when WiFi is lost AND mobile is available (line 35). Mobile being lost never triggers a reconnect.

Missed scenarios:

Mobile→Mobile handoff (signal drop + reconnect, cell tower switch): completely invisible

WiFi→WiFi switch (connecting to a different AP): if Android fires onAvailable for the new network before onLost for the old one (which it often does), isWifiAvailable is still true, so the condition !isWifiAvailable && networkType == WIFI is false → no notification

Ethernet or other transports: checkNetworkCapabilities silently ignores anything that isn't WIFI or CELLULAR (line 29-33 in NetworkChangeDetector)

Bug 3: onCapabilitiesChanged is logged but not acted on
NetworkChangeDetector.java:52-58

Some network switches (especially on newer Android versions) are signaled via onCapabilitiesChanged rather than onLost/onAvailable. This callback is completely ignored beyond logging.

Bug 4: EngineRestarter.isRestartInProgress can suppress subsequent changes
EngineRestarter.java:37-48

If a restart is in progress (up to 30s timeout), any new network change is silently dropped. Scenario:

Network change A triggers restart, engine begins stopping

Network change B occurs (the actual meaningful switch)

B is ignored because isRestartInProgress == true

Engine restarts with stale network state from A

Bug 5: Test coverage confirms the narrow design
ConcreteNetworkAvailabilityListenerUnitTest.java:102-120

The test shouldNotNotifyListenerNoNetworksAvailable asserts that WiFi lost without mobile available should NOT notify — this is by design, but means any single-network scenario (WiFi only, mobile only) will never trigger reconnects on network loss/recovery.

Summary
Bug 1 is almost certainly the primary culprit. The getNetworkCapabilities() call on an already-lost network returning null silently corrupts the state tracker, and once the state is stale, all subsequent transitions get filtered out. Bug 2 compounds this by making the reconnect trigger conditions extremely narrow even when the state is correct.

A fix would need to:

In onLost, determine the network type before or without calling getNetworkCapabilities on the lost network (e.g., by maintaining a Network → type map populated during onAvailable)

Broaden the reconnect triggers in ConcreteNetworkAvailabilityListener to handle mobile-only and same-type transitions

Optionally, handle onCapabilitiesChanged for more robust detection

---

The conclusions above seem interesting, but please take with a grain of salt. I'm not a Java programmer in any way, and know next to nothing about Android app programming.

[adboelens]

The last couple of days my connection has been very stable. The difference I can see is that there are active connections with other peers. I think this is because I enabled a routing peer in my setup. Maybe the app has trouble staying connected when there are no active connections, just available peers?

edit: I spoke to soon. The connection is somewhat more reliable, but still disconnects often. I think I will wait for the next update of the Android client. Hopefully, this can be improved.