LocalSend / engineering note

Available before the app is opened.

A short explanation of the Android background-availability change, the resource decisions behind it, and the limits that remain by design.

background path implemented

The problem

LocalSend already had the Rust HTTP server and multicast discovery, but both lived inside Flutter isolates that could be reclaimed when Android backgrounded the activity.

The fix

When Android moves the activity away, LocalSend starts a low-importance foreground service. That keeps the existing server and discovery isolates alive instead of adding a second networking stack.

Why this stays efficient

  • No polling loop, duplicate server, or extra native discovery daemon was added.
  • The service uses Android’s connectedDevice type for local-network device communication.
  • Idle discovery does not hold CPU wake or Wi‑Fi locks. Those locks are enabled only while a transfer is active.
  • The notification is low priority and is updated only when its content changes.

Windows

No new Windows process was needed. The existing tray, startup option, and authenticated single-instance handoff already keep the desktop side lightweight.

Re-evaluation

This is not a way to bypass Android’s force-stop behavior. The user must open LocalSend once and allow its foreground notification. If Android settings force-stop the app, the operating system stops its background work too.