Simplify nearby discovery: follow the app lifecycle and remove duplicate controls

[CodePandaaAI]

Why this change exists

You open Sync360 because you want to send text or a file to another device. Finding that device should feel like a natural part of sharing.

Previously, discovery had a 60-second window. When that window ended, scanning stopped while device advertising could remain active.

Reload button on send screen restarted only discovery scan, while Repair button on settings screen followed another path to recreate discovery and advertising.

Those distinctions had reasons in the code, but they gave users—and the maintainer—more things to understand.

This change asks a smaller question: what behavior does nearby sharing actually need?

The thinking behind it

Earlier changes to Sync360 questioned whether every interaction needed an approval step. Text moved toward direct delivery, files adopted a receive-code flow, and navigation moved toward showing one screen at a time.

Those are earlier changes, not features newly implemented in this PR. Their lesson shaped this work: sometimes the useful improvement comes from removing a decision or process altogether.

For discovery, that meant questioning the expiring scan and overlapping recovery controls.

We also learned that a simple explanation does not automatically produce simple code. An early implementation included connectivity monitoring and automatic refreshes after network changes. That added address tracking, callbacks, timing, and coordination beyond the behavior we wanted to establish.

That machinery was removed. The current scope is deliberately focused on app visibility and explicit user control.

The new Android behavior

Discovery stays active while Sync360 is visible, without a 60-second expiry.

When the app moves into the background, a two-second grace period is scheduled after Android's process lifecycle reports backgrounding. If the user returns before the pending stop runs, it is cancelled.

This avoids repeatedly tearing down discovery when someone briefly switches apps or rapidly backgrounds and reopens Sync360.

If the user stays away, discovery and advertising stop and clean up. Returning after cleanup allows a fresh session to start.

An explicit manual Stop is respected across background/foreground transitions until Start is pressed or a fresh app process launches.

Desktop retains its existing availability while minimized. iOS visibility integration is outside this change.

Fewer controls in a clearer place

Start and Stop live inside Nearby devices.

Reload and the separate Repair action have been removed. Repair had become another way to request a discovery restart, which users can already accomplish by stopping discovery and starting it again.

Because Repair was the only Settings item, its screen and the associated Troubleshoot shortcuts were removed too.

Actual start or cleanup failures still offer Try again.

The Nearby devices section now uses compact device rows and a straightforward empty state. Device taps continue through the existing sending flow; this change does not introduce a new pairing or selection protocol.

What happens after a network change?

The app does not inspect network changes or automatically refresh discovery.

If devices disappear after changing Wi-Fi or hotspot connections, users can stop discovery, wait for it to stop, and start it again.

This is an intentional tradeoff. Automatic recovery may be revisited later, after the existing behavior is better understood and validated.

Technical changes

• Added a small Android process-lifecycle observer with one cancellable delayed stop.
• Removed connectivity monitoring and network-address tracking.
• Centralized discovery intent in the shared controller.
• Reduced the platform contract to starting and stopping discovery and advertising.
• Removed the separate Repair command, refresh flag, and related presentation wiring.
• Gave Android scans explicit ownership of listeners and resolved results.
• Queued Android 13 legacy resolution.
• Checked late results against the active session and service instance.
• Kept failed callback cleanup retryable instead of pretending resources were released.
• Preserved the existing ownership of HTTP and file-transfer listeners.

The app still needs careful native cleanup. Simplification does not mean deleting necessary callback, socket, or resource handling.