v0.6.0 — Rebuild Android NSD around explicit ownership and readable flow

[CodePandaaAI]

Why this PR exists

This is a deliberately human-oriented refactor.

Sync360's nearby discovery code is important. It decides whether nearby devices appear, whether this device is visible to others, and whether the app can safely clean up and start again. It is also native Android code with asynchronous callbacks, legacy API paths, listener ownership, and lifecycle questions. That means it is exactly the kind of code that becomes risky when it works only because it was generated, copied, or made defensive in ways the current maintainer cannot comfortably explain.

The older Android NSD implementation was not treated as worthless. It was a useful reference and it contained defensive handling for difficult situations. But it was not the implementation I wanted to carry forward as the owner of this project. I wanted the code to read like the actual mental model of Sync360:

Start discovery.
Receive a service.
Resolve it when needed.
Publish a nearby device.
Remove it when it is lost.
Stop and release the callback/listener we own.

That simple story matters more here than reducing line count. Native networking code does not become easier merely because it is shorter. It becomes easier when each resource has an obvious owner, each callback has an obvious job, and future changes do not require trusting code that nobody fully understands.

What changed

The common NetworkServices contract is now split into four direct actions:

• startDiscovery()
• stopDiscovery()
• startAdvertising(httpServerPort, fileTransferPort)
• stopAdvertising()

This removes the old combined start/stop operation and makes the contract reflect what the app actually owns: browsing nearby services and advertising this device are related, but they are still separate native operations with separate callbacks and failures.

Android now uses the rebuilt AndroidNetworkServices implementation. Its intended discovery paths are explicit:

• Tiramisu SDK extension 22 or newer uses DiscoveryRequest and one ServiceInfoCallback for modern combined discovery, resolution, updates, and loss.
• Older supported Android uses DiscoveryListener plus the deprecated one-shot resolveService() API.
• Legacy resolves are serialized through a queue so only one resolution runs at a time.
• Advertising uses one RegistrationListener, shared by both discovery paths.
• Self devices are filtered by Sync360's stable device UUID before being published.
• Discovery and registration expose real platform states such as Starting, FailedToStart, Running, Stopping, and CleanupFailed.

The controller was simplified at the same time. It now starts the HTTP server and file-transfer receiver once, then directly asks the platform service to start or stop nearby sharing. It exposes the nearby-device list and the real platform discovery/registration statuses. The Send UI no longer keeps a separate isDiscoveryEnabled boolean or a generic discovery-error string that can contradict Android's actual state.

Instead, the UI has a direct relationship with discovery status:

Idle            → Start
Starting        → Stop
Running         → Stop
Stopping        → Stop
FailedToStart   → Try again
CleanupFailed   → Try again

Desktop and iOS were updated to implement the same explicit common contract. This is contract alignment, not a claim that every platform backend has received the same level of manual validation as Android.

Why this is intentionally not "just fewer lines"

The old implementation may have covered some edge cases more aggressively. This PR does not claim that every removed layer was bad or that the new implementation has magically solved every native networking problem.

The point is different: this code can now be read from top to bottom by the person responsible for it.

A future fix should begin with understandable questions:

• Which listener or callback do we currently own?
• Did Android accept the start request or only receive it?
• Which callback confirms completion?
• Which status should the UI show?
• Can this legacy result still belong to a service that is present?
• What must be retained after cleanup fails?

That is a better foundation for reliability than an implementation which might be more defensive on paper but is too opaque to change with confidence.

Current confidence and honest limitations

Normal Android foreground discovery has been manually observed during this work: devices were added and removed in normal conditions.

This is still a preview release and not a claim of complete NSD maturity. Known follow-up areas include:

• Android 17 local-network permission handling is still missing.
• Lifecycle overlap, startup/stop overlap, and broader cleanup-failure validation need more device testing.
• Legacy discovery still needs more presence/session tracking so a late legacy resolve cannot publish a device that was already lost or stopped.
• Modern multi-network ownership needs stronger service-name-plus-network tracking.
• Registration status is exposed separately, but the Send UI currently concentrates on discovery status.
• Desktop, iOS, adapter, VPN, hotspot, firewall, and physical-device validation remain broader work.

These are not hidden from this PR. They are simply not being solved by pretending this release is finished when its real achievement is clarity, ownership, and a much better base for deliberate future work.

Versioning

• Android version name: 0.6.0
• Android version code: 10
• Desktop package version: 0.6.0
• iOS marketing version: 0.6.0
• iOS build number: 10