Wi-Fi Aware Discovery for Instruments: Define Session Lifetimes Before Data Transfer

Discovering a Wi-Fi Aware service does not create a usable data socket. An application must own the Aware attachment, discovery session, peer handle, network request and socket as separate resources. Give each operation a lifetime and reject callbacks belonging to retired work before allowing an instrument transfer to begin.

This guide uses Android 15, API level 35, with source pinned to android-15.0.0_r1. It addresses an Android-side instrument client and a separately qualified compatible peer. Wi-Fi Aware is also called Neighbor Awareness Networking, or NAN. A device’s ordinary Wi-Fi capability does not prove Aware support, current availability or compatibility with the peer’s data-path security configuration.

Gate capability, availability and permission separately

Check the platform’s Wi-Fi Aware feature and current isAvailable() state. Register for availability changes before the initial state query to avoid missing a transition. Aware availability can change with user settings and radio-resource combinations; a supported device can be temporarily unavailable. Android’s guide also separates the permission requirements by target API and whether the application derives location. Declare neverForLocation only when that assertion is true for the product. Android Wi-Fi Aware overview

Do not turn these checks into one “unsupported” error. A missing feature, denied permission, unavailable service and resource exhaustion require different operator messages. Record the actual OS build, target SDK, hardware and peer implementation in the qualification matrix. Available-resource counts are advisory observations, not reservations against concurrent applications.

Represent five owned resources

Resource	Created by	Application ownership rule
Aware attachment	Successful attach callback	One current parent session for this workflow
Publish/subscribe session	Successful discovery-start callback	Belongs to the parent attachment epoch
Discovered peer	Discovery or message callback	Opaque handle scoped to its discovery context
Requested data network	ConnectivityManager request and callbacks	Track request identity and the returned Network
Transfer socket	Application opens it on that Network	Close on transfer end or applicable network loss

In the pinned Android source, closing WifiAwareSession terminates its discovery operations and outstanding data links. The documentation still recommends explicitly destroying discovery sessions and connections before closing the parent. Garbage collection is not a timely resource-release strategy. Android 15 WifiAwareSession

Assign monotonic application generations to parent attachments and individual network requests. Capture the generation when launching asynchronous work. On cancellation or parent disruption, invalidate that generation before cleanup. A delayed successful callback from an older request must not become the current network merely because the app has started another discovery cycle.

Use discovery messaging for coordination, not completion

The discovery callback supplies an opaque PeerHandle. A successful discovery-message send means the peer acknowledged that message at the documented transmission boundary; it does not establish a data network or prove that an instrument accepted an application command. Preserve discovery-message IDs separately from transfer IDs. Android 15 DiscoverySessionCallback

Keep any coordination envelope bounded and versioned. Include the application protocol version and a fresh transfer correlation value, while retaining the intended peer-authentication design. A familiar service name or discovered handle is not a product ownership credential. Select a supported protected data-path configuration and authenticate the application peer before releasing sensitive operations; this guide does not prescribe shared secrets or automatic trust acceptance.

Wait for the network and usable endpoint information

Request the Aware network for the intended discovery context and peer. The Android guide obtains a Network through onAvailable(), then obtains peer information from the capabilities callback. Its socket example uses that network’s socket factory, keeping the transfer on the selected Aware path rather than an unrelated default network. Release the request through its registered network callback when finished. Android Aware data-connection procedure

In Android 15, WifiAwareNetworkInfo describes the peer’s IPv6 address, port and transport protocol. Port zero means the peer did not specify a port, and protocol minus one means unspecified. Do not turn either sentinel into a usable endpoint. Require the expected capabilities and endpoint fields for the same current Network before opening the socket. Android 15 WifiAwareNetworkInfo

Discovery loss and data-network loss are separate observations. Mark a lost discovered service unavailable for new work, but do not invent a platform guarantee that every discovery-loss event immediately describes socket state. Use the network callback and socket outcome for the transport, with the product’s own timeout and teardown policy. A stale loss callback must not close a newer transfer.

Qualify lifecycle failures explicitly

1. Normal discovery and transfer. Correlate parent attachment, discovery start, peer event, network request, capabilities and an authenticated application exchange. Record which event first permits each state transition.
2. Peer disappears before data setup. Require a bounded unavailable outcome and release the pending request. Discovery success must not leave the UI waiting indefinitely for a socket.
3. Parent availability changes. Invalidate the old workflow, close owned resources and re-check availability. Reattach only through a new epoch; never reuse old peer handles as current state.
4. Cancel while callbacks are queued. Deliver or replay late discovery and network callbacks in a test harness. They must not revive a canceled transfer or overwrite its replacement.
5. Lose the data network during transfer. Stop using the affected socket, preserve the application’s partial-transfer contract and release its network request. Do not count a discovery message acknowledgment as data recovery.
6. Repeat resource cycles. Exercise successful, failed and canceled sessions until the product’s test budget is met. Check that session/request counts return to the declared baseline and that failure does not leak a permanent discovery operation.

For a hypothetical handheld analyzer, an old network request completes after the user cancels instrument A and selects instrument B. The callback’s old request generation must be rejected even if both advertise the same service name. This is an ownership test, not an RF performance claim.

Evidence boundary

The Android 15 API/source paths and current official guide were inspected. No Android app, Aware radio, peer data path or socket transfer was executed for this article. The failure cases are proposed integration tests.

Release with an ownership ledger, current-generation callback rules, endpoint-readiness gate and cleanup evidence. Those artifacts make discovery a controlled prerequisite for transfer rather than an ambiguous “connected” indicator.